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Para tal a A.P.!. procurará: 


— Promover o intercâmbio de conhecimentos técnicos; 
— Contribuir para o desenvolvimento do ensino da Infor- 


mática; 


— Promover Congressos, Conferências e Exposições sobre 


informática; 


A A.P.I. é uma associação profissional, sem carácter sindi- 
cal, sem fins lucrativos, exercendo a sua actividade em todo o 
território português (do Art. 1º dos estatutos). 

Encontram-se em funcionamento duas Delegações Regio- 
nais com sede respectivamente no Porto e em Lisboa. 

A Associação tem fins culturais e científicos que contri- 
buam para o aperfeiçoamento e progresso técnico, económico 
e social e para divulgação das técnicas informaticas. 


ASSOCIAÇÃO PORTUGUESA DE INFORMÁTICA 


Com fins profissionais: 


— Definir a profissão de informática nos diversos estados 
do seu desenvolvimento; 

— Enquadrar a profissão de informática no conjunto das 
outras profissões; 

— Prestar colaboração aos organismos sindicais no sentido 
de melhor enquadramento e defesa dos trabalhadores de 
informática no âmbito da contratação colectiva. 


(do Arte 5º dos estatutos) 


A A.P.|. edita uma revista e um boletim de distribuição 


gratuita para os sócios. 


Tem constituídos alguns grupos de trabalho que se 


debruçam sobre temas quer de interesse geral como é o 


caso do grupo “Profissão”, quer sobre problemas mais 


específicos como por exemplo “Bancos de dados”. 


— Prestar colaboração e cooperar com entidades nacionais 


e estrangeiras em assuntos de informática. 


(do Art: 4º dos estatutos) 


1. Os originais deverão ser envia- 
dos para a sede da API, Avenida Almi- 
rante Reis, 127, 1.0 Esq.º, Lisboa, 
dirigidos ao Director da Revista. 


2. Os originais devem ser dactilo- 
grafados a dois espaços em folhas 
brancas normalizadas (tipo A-4). As 
gravuras devem ser aceitáveis para a 
tipografia. Os gráficos, esquemas e ou- 
tros desenhos devem pautar-se pela 
mesma regra, sendo apresentados em 
papel vegetal e desenhados a tinta-da- 
-china. As gravuras, desenhos e outras 
figuras devem estar numerados e 
acompanhados das respectivas legen- 
das. 

A ordem do texto deve ser: título, 
nome do autor, local de trabalho e/ou 
instituição de apoio, resumo em por- 
tuguês, resumos em inglês ou francês e 
artigo propriamente dito. O artigo 
deve ser dividido em secções numera- 
das, como por exemplo: 

1. introdução 

2. definição de uma rede de com- 

putadores 

3 topografia de redes 

4. agradecimentos 

5. referências 


Para que a Associação alcance o lugar que lhe é de- 


vido necessita da colaboração de todos. 


inscreve-te como sócio, a quota é de 20800, e cola- 


INSTRUÇÕES AOS AUTORES 


3. As referências a autores e obras 
devem obedecer ao seguinte padrão: 
(Raphael, 1976); (Gelenbe, 1971); 
(Aho, Hopcroft e Uilman, 1974). O 
que corresponderia, nas referências 
bibliográficas apresentadas no final do 
trabalho, a: 


Raphael, B. — The thinking computer 
— Mind inside matter. 
W.H. Freeman, 1976. 


Gelenbe, E. —The rule for dynamic 
storage allocation under equili- 
brium. 

Information Processing Letters 1, 
59-60, 1971. 


Aho, A.V.; Hopcroft, J.E.; Ullman, 
D.D. — The design and analysis 
of computer algorithms. 
Addison-Wesley, 1974. 


4. Os vocábulos estrangeiros de- 
vem, nos originais, ser apresentados 
em sublinhado (indicação de itálico) e 
não entre aspas, salvo quando se tratar 
de citações de textos. 


bora nas actividades da nossa Associação 


5. Os artigos devem ser acompe- 
nhados de um pequeno resumo em 
inglês e/ou francês, além de um resu- 
mo em língua portuguesa. 


6. Os autores devem indicar as pa- 
lavras-chave dos seus trabalhos. 


7. Os autores têm direito a cinco 
exemplares da revista em que os seus 
trabalhos forem publiccios, grá- 
tis. No caso de pretenderem um núme- 
ro mais elevado de revistas, deverão 
contactar com antecedência a Redac- 
ção de Informática, onde serão infor- 
mados acerca das condições para tal. 


8. Os artigos publicados são da res- 
ponsabilidade dos respectivos autores. 


9. Informática está aberta a toda a 
colaboração, não se responsabilizando, 
contudo, pela publicação dos originais 
não solicitados. Estes originais serão 
sujeitos à apreciação crítica da Direc- 
ção da Revista e do seu Conselho da 
Redacção. Em caso de recusa de publi- 
cação, os autores serão informados das 
respectivas razões. 


fe 
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CII Honey well Bull 


O conteúdo desta revista é «copy- 
right». A sua reprodução, total ou 


Fitacom 41 A. SERNADAS — Bases de Dados em esta- parcial, sem autorização do Director 
tística pe 

é proibida. 

ICL 47 Referências: o mercado dos SGBD 

NCR 

TEOR A opinião expressa nos artigos assi- 
nados é da responsabilidade dos seus 

UNIVAC A publicidade ficará a partir do próximo autores e não exprimem necessaria- 

número a cargo da Agência Multiplo. mente a opinião da API ou da Redacção 
UNL da Revista. 
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segundo original de Puig Rosado 
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ADMITA UM NOVO E EFICIENTE COLABORADOR 
PARA A SUA EMPRESA 
O COMPUTADOR 61/40 DA CIl HONEYWELL BULL 


O computador 61/40 é um cola- 
borador eficaz e económico que ne- 
cessita de um espaço reduzido para 
se instalar. 


Sendo um verdadeiro computador, 
embora de baixo custo, tem grande 
flexibilidade, respondendo rapida- 
mente a todas as necessidades, tais 
como o processamento de vencimen- 
tos, facturação, controlo de stocks 


Cii Honeywell Bull 


salários, contabilidade, etc., e forne- 
cendo mapas de gestão indispensá- 
veis à actividade da sua empresa. 


O computador 61/40 é de fácil uti- 
lização e a sua capacidade de diálogo 
é enorme. Permite a outros colabo- 
radores da sua empresa acederem, 
através de terminais, às informações 
de que dispõe. 

Fabricado em França, o compu- 
tador 61/40 é já um colaborador de 
milhares de empresas espalhadas por 
todo o mundo. 


Se desejar mais informações sobre 
o seu futuro colaborador — o compu- 
tador 61/40 — contacte, mesmo pelo 
telefone, a Cii Honeywell Bull. Em Lis- 
boa, fale com Carlos Vidinha e, no 
Porto, com Oliveira Santos. Ou escre- 
va-lhes, se preferir. 


Escolha um bom colaborador. 
Escolha um 61/40. 


Lisboa: Av. 5 de Outubro, 35-6.º 
Telefs. 5341 81/54 99 26 


Porto: Rua Júlio Dinis, 825-3.º 


MUDE PARA A INFORMÁTICA CRIATIVA Telefs. 69 21 69/69 21 60 


Es 
INFORMÁTICA 
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EDITORIAL 


INFORMÁTICA 


““Rien ne presse un Etat que l'innovation” 


Montaigne 


No princípio era o computador — a máquina, o utensílio que se propunha 
substituir o homem no seu domínio intelectual. 

Norbert Wiener acabava de apresentar a Cibernética como “'ciência do con- 
trole e da comunicação no animal e na máquina” e integrava a equipa que 
construiria o primeiro computador. 

Depois, a década de 60 consagrou a Informática. Já não se tratava só da má- 
quinu, mas do tratamento automático da Informação. Tratava-se da “ciência 
do tratamento sistemático e eficiente, especialmente por meio de máquinas 
automáticas, da informação vista como suporte do conhecimento humano e 
servindo a comunicação nos domínios técnicos, económicos e sociais” 

Com os anos 70 veio a consagração de uma disciplina do conhecimento hu- 
mano, que dia a dia se sobrepunha em inovações tecnológicas e em realiza- 
ções ambiciosas. Aonde vão as válvulas, os transistores, a linguagem máqui- 
na, o faz-tudo-informático, o endeusamento dos informáticos, a informática 
das grandes salas de máquinas, a aplicação isolada, que ainda ontem cara- 
cterizavam a INFORMÁTICA e hoje mais não são do que a pré-história ou a 
sua manifestação desactualizada? 


Todos nós estamos familiarizados com expressões como sistema solar, sis- 
tema nervoso, sistema fiscal ou sistema social. 

E. vem isto a propósito porque também, desde não há muito tempo, se co- 
meça a falar de sistemas informáticos - sistemas de tratamento automático 
da informação - apresentando-os como subconjuntos dos sistemas de infor- 
mação, o que nos leva à chamada teoria dos sistemas (“SYSTEMS 
APPROACH '"'). 

Teoria dos Sistemas, que na década de 60 ganha grandes desenvolvimentos 
no domínio da informação, resultantes do progresso tecnológico conseguido 
nos computadores e simultaneamente da verificação prática de investiga- 
ções que nos anos atrás se levavam a cabo no domínio da informação. 
Evidentemente que já havia sistemas de informação muito antes dos compu- 
tadores (entre todos, os maiores sistemas de informação que herdámos do 
passado foram as bibliotecas) mas a verdade é que com eles se multiplicou 
fantasticamente a velocidade de processamento e se dotou a Humanidade de 
utensílios capazes de memorizar infindáveis quantidades de informação. 

Por outro lado, essa nova perspectivação dos organismos ( “systems 
approach'" — enfoque sistémico) veio pôr a descoberto a importância vital 
da informação — seja no organismo humano (tivemos conhecimento de uma 
tese apresentada em simpósio internacional em 1974 que definia a morte co- 
mo o momento em que o organismo deixava de poder processar a informa- 
ção seja no organismo social. 

E, qualquer observador menos atento dos nossos dias, se apercebe minima- 
mente da importância e valor da informação no agregado a que pertence — 
dos jornais à televisão, aos ficheiros de segurança social e da polícia, à priva- 
cidade, etc. — na empresa, na repartição, no País, na economia, bem como 
na velocidade com que se estabelece a comunicação no seio das comunida- 
des e entre elas. 

Tudo isto dá valor e actualidade ao problema dos sistemas de informação 
que constituem hoje, nas suas variadas aplicações e manifestações, motivo 
de preocupação e estudo por parte de cientistas, investigadores e responsá- 
veis políticos. Isto é: o estudo da informação não deve ser perspectivado iso- 
ladamente, como produto de determinada actividade ou o conteúdo de uma 
qualquer mensagem, mas como resultado de um conjunto de elementos de- 
vidamente estruturados, actuando segundo regras de funcionamento devi- 
damente estabelecidas, com vista à consecussão de um objectivo comum. 

E são as preocupações daqueles e a unanimidade com que se vai aceitando 
esta perspectivação sistémica do fenómeno informação que conferem verda- 
de à afirmação de que a informação é de facto fonte de Poder. 
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3. “L'informatisation de la Societé”, ou o relatório Nova/Minc, como vai sendo 
conhecido, é disso prova cabal. 
Solicitado pelo Presidente da República Francesa em Dezembro de 1976, 
acaba de ser publicado em França (La documentation française, Junho 78) 
um relatório sobre “Os meios de conduzir a informatização da sociedade”, 
da responsabilidade de Simon Nora, que obteve a colaboração de dezenas de 
técnicos de reputada credibilidade. 
Documento de incontestável valor para análise de diagnóstico e previsão da 
evolução da informática, ele dá bem nota da importância crescente de que se 
reveste o tratamento automático da informação nas sociedades humanas. 
Particularizado à situação da França o relatório põe contudo em destaque si- 
tuações e problemas comuns à generalidade dos Países. 
E quer 
—pela introdução de um novo conceito (telemática), que evidencia a inter- 
relação crescente entre a informática e as telecomunicações e que dife- 
rentemente da electricidade, veiculará não só corrente inerte, mas in- 
formação, o que quer dizer Poder; ou 
—pela análise do impacto da informação automatizada no emprego, nas 
relações de comércio internacional, na alteração das relações de poder, 
na independência nacional, na informatização da administração públi- 
ca, etc., 


O relatório agora publicado deverá merecer de todos os responsáveis a aten- 

ção e o dimanar de decisões que encaminhem a Sociedade Portuguesa para o 

seio da Comunidade Mundial, aonde se começa a admitir que no final do sé- 

culo, o sector informátco será o segundo sector económico (em população de 

emprego e volume de negócios) depois da Construção e antes do Automóvel. 

E aonde já se vai caminhando para a chamada informática capilar -resultante 

da informática e das telecomunicações (telemática) e da tecnologia dos mi- 
croprocessadores -que penetrará em todos os sectores da actividade humana 

antes do fim do século: domicílio, escritórios, oficinas, diversões e recreio, 

etc. 

Desenvolvimentos, contudo, que atingirão os valores de liberdade e privaci- 

dade e que exigirão técnicos apurados de segurança e fiabilidade para a in- | 
formação. 

E se nos dominios das tecnologias das matérias, da vida e da energia, já na- | 
da há a fazer porque estamos irremediavelmente nos últimos lugares, que 
não se perca a corrida da tecnologia da informação. 

Ao menos que se mantenha alguém no Grupo da frente...para informar. 


Almiro de Oliveira 
Out. 78 


UNIVAC 90/30 


MICROPROGRAMAÇÃO 
MULTIPROGRAMAÇÃO 
EMULAÇÃO 
COMPATIBILIDADE 


LINGUAGENS DE ALTO NÍVEL 
CRESCIMENTO 


SPER?y <> LINIVAC 
O Sucesso dos Nossos Clientes é o Nosso Sucesso 


SPERAY UNIVAC é uma divisão da Sperry Rand Corp. 
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LIVROS: NOTAS DE LEITURA 


= Siad TE DN DS 


“Date, CJ. - An introduction to data 
base systems Addison-Wesley, 
Pub. Comp. 2nd. ed., 1977. 


O livro “AN INTRODUCTION TO 
DATA BASE SYSTEMS” de C.J. Date 
é das poucas publicações (juntamente 
com o nº1 (Vol. 8, 1976) do Computing 
Surveys) que fazem uma apresentação 
dos três principais tipos de “package” 
para Gestão de Bases de «Dados (habi- 
tualmente chamados “Sistemas de 
Gestão de Bases de Dados” (SGBD): 
hierárquicos, em rede e relacionais. 

C.J.Date trabalhou com o investiga- 
dor da IBM a quem se devem os funda- 
mentos teóricos dos SGBD relacionais 
(E.F.CODD). Talvez por isso, enferma 
duma ênfase excessiva neste tipo de 
SGBD. Por um lado, é-lhes dedicada 
uma grande (senão a maior) parte do 
livro, e por outro, eles servem de refe- 
rência para a apresentação dos siste- 
mas hierárquicos e em rede. A confu- 
são entre as possibilidades dos SGBD 
relacionais (que ainda não estão co- 
mercializados) e as possibilidades dos 
outros SGBD, aparece em vários pon- 
tos do livro. 

Desde que esteja prevenido, no en- 
tanto, o leitor poderá ficar com uma 
boa ideia das linguagens dos vários 
SBGD focados (IMS e SGBD CODA- 
SYL), dos mecanismos para o controle 
de confidencialidade (descrição muito 
completa) e das estruturas de dados 
(apresentação muito clara e sucinta). A 
regulação da concorrência (“multi- 
user”) e a preservação da integridade 
física (recuperação de dados) são abor- 
dados muito ao de leve. 


Bobines de fita para perfurar 


Bandas magnéticas «Racal-Zonal» 
Discos magnéticos «Nashua» 
Diskettes «Nashua» 


NFORMÁTICA 


FIT ACO M — MATERIAL PARA 


ACESSÓRIOS PARA CENTROS MECANOGRÁFICOS : 


Todo o equipqmento acessório para mini-computadores pe 
Etiquetas auto-colantes em contínuo 


Pastas especiais para arquivo de formulário em contínuo 
Fita tinta para impressoras de computadores 


“AN INTRODUCTION TO DATA 
BASE SYSTEMS” divide-se em 5 
PARTES: 


— Na “PARTE 1'' são apresentadas 
boas definições dos conceitos gerais 
dos Sistemas de Gestão de Bases de 
Dados, um resumo das vantagens de 
integrar um conjunto de dados, uma 
má explicação do que é a “data-inde- 
pendence”” (independência da progra- 
mação em relação aos detalhes da or- 
ganização física dos dados), princípios 
teóricos de arquitectura de SGBD, um 
resumo das estruturas de dados em- 
pregados e uma explicação sumária 
dos 3 tipos de SGBD. 


— Na “PARTE 2'' descreve-se o 
Modelo Relacional que é a base teórica 
dos SGBD relacionais em vias de im- 
plementação, dos pontos de vista da 
definição e manipulação dos dados. As 
linguagens apresentadas para uma e 
outra não são linguagens existentes 
mesmo nos protótipos mas antes os 
“esqueletos teóricos” das linguagens 
de tais sistemas. O método de apre- 
sentação é muito bom e capaz de sedu- 
zir mesmo o leitor sem qualquer pre- 
paração em lógica. 

Ainda nesta PARTE 2 dá-se grande 
enfase ao contrôle de confidencialida- 
de. O mesmo se pode dizer quanto à 


“normalização” o que é menos razoá- 
vel pois embora seja tal conceito im- 
portante, não cabe numa introdução. 


— Na “PARTE 3"', que é dedicada 
ao SGBD IMS, sistema de maior ex- 
pansão dentro dos hierárquicos, come- 
ça-se por uma boa apresentação das 
Bases de Dados IMS, e prossegue-se 
com elementos da linguagem de defi- 
nição e da linguagem de manipulação 
(DL/1) correspondentes. Os capítulos 
13 e 14 descrevem com grande clareza 
as estruturas de dados utilizadas por 
IMS. 


A “PARTE 3" parece ser uma boa 
introdução à IMS. 


— Na “PARTE 4" dedicada aos 
SGBD CODASYL (representantes 
mais divulgados dos SGBD em rede) 
são explicadas com detalhe as constru- 
ções tanto da linguagem de definição 
como da linguagem de manipulação. 


— A “PARTE 5", será uma dece- 
pção para quem pretender uma apre- 
sentação dos vários mecanismos de 
contrôle da Segurança e Integridade 
existentes nos SGBD, ou pretenda 
uma apresentação científica dos pro- 
blemas que tal contrôle envolve. 


MECANOGRAFIA, LDA. 


6 Equipamento acessório para IBM — Sistema/3 
Mobiliário para arquivo de: 


— Cartões perfurados 


— Discos magnéticos 
— Bandas magnéticas 
— Diskettes 


6 Mobiliário especial para diskettes 


6 Cofres monobloco à prova de fogo e humidade «Lampertz» 


LARGO DOS LÓiÓS, 3-A — TELEF. 87 54 50 — LISBOA - 2 
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Y Inteligência distribuida por vários subsistemas 
independentes, executando funções de proces- 
samento. São conectados entre si através de 
um “ITB” (Internal Transfer Bus) ligado a um 
controlador. 


y Lógica “firmware”, carregada através de um 
disco flexível, permite a concretização de máqui- 
nas virtuais múltiplas, entre as quais é de destacar 
a máquina virtual COBOL, que torna esta lin- 
guagem altamente eficiente. 


Y Poderoso sistema operativo com gestão auto- 
mática e dinâmica, possibilitando executar até 
35 aplicações simultâneas, dando elementos 
para o controlo financeiro, económico e esta- 
tístico da instalação. 


Y Exploração em memória virtual múltipla. 


V Altos níveis de segurança, disponibilidade e 
eficiência (RAS). 


y Compatibilidade total com os sistemas NCR 
Century. 


REVISTA DA IMPRENSA 


TRABALHADORES LUTAM PELA POLÍTICA NACIONAL DE INFORMÁTICA 


Quando se fala de computadores e 
de independência nacional, as pessoas 
são fatalmen:” assaltadas por um con- 
junto muito vasto de questões, como o 
atraso científico e tecnológico portu- 
guês; as consequências económicas, fi- 
nanceiras e políticas que derivam des- 
se atraso; as possibilidades de utiliza- 
ção dos computadores para a constru- 
ção da independencia nacional; etc. 


Neste momento estão a funcionar 
em Portugal centenas de computado- 
res das mais variadas dimensões, to- 
dos eles importados. Essas importa- 
ções que não obedecem a qualquer po- 
lítica ou plano, são feitas quase total- 
mente através de sucursais multinacio- 
nais.americanas aqui instaladas. Nal- 
guns casos, estas sucursais registam 
facturações anuais da ordem do meio 
milhão de contos. 

A concepção e a produção dos com- 
putadores pressupõe um desenvolvi- 
mento científico e tecnológico que está 
fora das possibilidades portuguesas. 
Além disso, as regras do mercado 
mundial tornam impossivel pensar em 
substituir uma parte significativa das 
importações por produção nacional, 
pelo menos a curto ou médio prazo. 
Assim, no plano imediato, a questão 
que se coloca é a de comparar as cente- 
nas de milhares de contos em divisas 
que Portugal paga anualmente para 
importar os computadores com o resul- 
tado social da sua utilização. 

Na verdade, o tipo de utilização dos 
computadores que se pratica no país é 
uma outra frente polémica, pois prati- 
camente não tem nada a ver com o au- 
mento da produção, nem com a maior 
eficiência dos serviços de carácter so- 
cial que se destinam à generalidade da 
população (como o ensino, a saúde, a 
habitação, etc.). Entretanto, este as- 
pecto do problema não será desenvol- 
vido aqui. O objectivo deste artigo é 
mostrar a necessidade de uma Política 
Nacional de Informática (PNT) e os pas- 
sos dados até hoje para a sua formula- 
ção. 


NECESSIDADE DA PNI 


Considerando a importância cres- 
cente dos computadores em todos os 
aspectos da vida (especialmente na 
produção) e a total dependência do es- 
trangeiro para a sua aquisição, é intri- 
gante que seja tão reduzido o número 
de intervenções públicas que tratem 
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do assunto à luz de uma perspectiva 
nacional. Actualmente, pode dizer-se 
que os portugueses se encontram na 
fase de tomada de consciência dos 
seus problemas, da sua identidade 
nesse sector. Fase que tem, necessã- 
riamente, de anteceder a formulação 
da Política Nacional de Informática. 


E evidente que, do ponto de vista na- 
cional, há problemas, interesses e 
objectivos particulares—distintos e in- 
dependentes dos outros países. Assim, 
alguém ou alguma entidade terá de de- 
finir, encarnar e interpretar esses pro- 
blemas, interesses e objectivos. Tam- 
bém é evidente que quanto mais parti- 
cipada e organizada fôr a formação de 
tal consciência, mais representativa 
será a caracterização dos interesses e 
maior será a adequação aos objectivos 
nacionais no campo da informática. 

Por outro lado, as experiências es- 
trangeiras iniciadas há muito mais 
tempo revelam a influência dos inte- 
resses de classe na formulação das po- 
líticas de informática. Na realidade, as 
políticas nacionais são decisivamente 
condicionadas pelos interesses de clas- 
se. Assim, existe uma enorme diferen- 
ça entre as experiências em informáti- 
ca de uma França capitalista e as de 
uma Cuba socialista, por exemplo. Da 
mesma forma, as relações económicas 
e tecnológicas que se praticam entre os 
países capitalistas avançados e as que 
se praticam entre os países socialistas 
obedecem a lógicas muito diferentes. 

De um lado, verifica-se o domínio 
económico e tecnológico quase total 
por parte de um país, osEUA, que es- 
maga qualquer veleidade de concor- 
rência, mesmo por parte dos países ca- 
pitalistas mais avançados (os casos da 
Cll e da Unidade são exemplares). Do 
outro, uma sadia cooperação interna- 
cional em que os Estados socialistas 
partilham os avanços tecnológicos e 
planeiam a produção em conjunto (por 
exemplo: distribuindo entre si a fabri- 
cação de diferentes modelos de uma 
mesma linha de computadores). 

No seu conjunto, os países socialis- 
tas foram alvo de um boicote tecnológi- 
co. Isto forçou-os a desenvolver a sua 
própria tecnologia e a produzir a quase 
totalidade dos seus equipamentos con- 
tando apenas com as suas forças. 


Por sua vez, os países capitalistas, 
inseridos no sistema imperialista mun- 
dial, têm acessos mais ou menos vio- 


lentos de “'nacionalismo” no campo da 
informática. Contudo, como tais aces- 
sos têm como protagonistas os gover- 
nos e os grandes grupos financeiros, 
as suas tentativas de resistência à do- 
minação americana estão destinados 
ao fracasso. Isso, porque eles utilizam 
a mesma lógica daqueles com quem 
pretendem concorrer: querem lutar 
num mercado mundial moldado pelos 
norte-americanos utilizando as mes- 
mas armas (técnicas de marketing e 
superioridade tecnológica) —por isso 
já partem com grande desvantagem. 
Além disso, como estas experiências 
se radicam no ''nacionalismo”, tal co- 
mo o entendem os grandes grupos fi- 
nanceiros, nem sequer se consegue a 
indispensável cooperação internacio- 
nal frente ao gigantismo dos EUA. 

De qualquer forma, com maiores ou 
menores sucessos, já existe uma vasta 
corrente mundial no sentido de cada 
país defender a sua independência —o 
que não significa, de modo algum, iso- 
lamento ou ausência de relações eco- 
nómicas. A própria ONU já tomou po- 
sição no que respeita ao apoio a países 
em vias de desenvolvimento, a fim de 
que possam tirar partido da informáti- 
ca como instrumento para a superação 
das suas dificuldades. Assim, é nesta 
vasta corrente que Portugal tem de vir 
necessariamente a integrar-se, formu- 
lando e levando à prática um PNI. 


CONTRIBUIÇÃO 
DOS TRABALHADORES 
PARA FORMULAÇÃO DA PNI 


O carácter revolucionário do 25 de 
Abril repercutiu-se em todos os cam- 
pos da vida nacional. Na informática, 
trouxe a convicção de que era possível 
a criação e a afirmação de uma pers- 
pectiva nacíonal para libertar o país da 
sua dependência quase total. É signifi- 
cativo que tenham sido gs trabalhado- 
res portugueses, com todas as suas li- 
mitações; os primeiros a tentar dar os 
primeiros passos nesse sentido. 

Logo após o 25 de Abril, gerou-se 
grande polémica entre os trabalhado- 
res da informática acerca da eventual 
criação de um sindicato que os repre- 
sentasse. O facto de ter prevalecido a 
opinião que se opunha a tal criação 
significa, por um lado, a rejeição da 
pulverização sindical e do sindicalismo 
horizontal. Por outro lado, significa a 
consciência de que os maiores proble- 
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mas dos trabalhadores da informática 
só terão solução no quadro da defesa 
da independência nacional. 

Afinal, toda a polémica gerada à vol 
ta da tentativa de criação do “Sindica- 
to Livre dos Profissionais de Informáti- 
ca” saldou-se pelo virar das atenções 
em direcção à Associação Portuguesa 
de Informática. Esta já existia e rece- 
beu, então um novo influxo de entusi- 
asmo e adesão. De certa maneira, es- 
tes factos decidiram muito do que veio 
a passar-se posteriormente. Entretan- 
to, houve três acontecimentos que fo- 
ram marcos no difícil caminho percor- 
rido pelos trabalhadores rumo a uma 
perspectiva nacional no campo da in- 
formática. 


O primeiro foi o Encontro Europeu 
de Trabalhadores da IBM. Em Junho 
de 1975, os delegados sindicais e a Co- 
missão de- Trabalhadores da IBM (o 
maior produtor mundial de computa- 
dores) promoveram em Lisboa esse en- 


contro internacional de trabalhadores - 


da sua empresa. Reuniram-se aqui tra- 
balhadores franceses (CGT e CFDT), 
espanhóis, suecos (SIF/TCO), italia- 
nos (FLM) e holandeses. Por razões 
políticas, as centrais sindicais de cer- 
tos países sociais-democratas recusa- 
ram-se a participar. 

A simples realização daquele encon- 
tro teve uma enorme importância. Foi 
uma tentativa, pouco comum, de coor- 
denação sindical a nível internacional 
frente a uma entidade patronal que é 
uma das maiores multinacionais do 
mundo. Também no aspecto específico 
da informática a experiência foi impor- 
tante: eram os próprios trabalhadores 
a tentar abrir caminho à cooperação in- 
ternacional, forma privilegiada de re- 
forçar o poder de negociação de Portu- 
gal. 

Este é um caso exemplar, onde a de- 
fesa dos interesses de carácter sindical 
dos trabalhadores se interliga de for- 
ma evidente com a defesa da indepen- 
dência nacional. É bem representativo 
da perspectiva patriótica dos trabalha- 
dores o facto de terem estado no en- 
contro, como convidados, . elementos 
das comissões de trabalhadores e co- 
missões sindicais de outras empresas 
do mesmo ramo. Empresas que, de 
acordo com as regras da concorrência, 
se degladiam no mercado nacional e 
mundial. A condição de portugueses e 
de trabalhadores superava a condição 
de empregados de uma determinada 
marca de computador. 


Assim, diz o comunicado final do en- 
contro, “conscientes de que os operá- 
rios, empregados, técnicos e enge- 
nheiros da IBM devem subordinar as 
actividades da companhia às necessi- 
dades dos seus países e povos, foi de- 
cidido criar uma Comissão Coordena- 
dora”. Esta, composta por elementos 
dos países presentes, tem permitido a 
troca de informação e de experiências. 

O desenvolvimento de iniciativas 
deste tipo, em paralelo com outras a 
nível governamental, permitirá a Por- 
tugal aprender com os erros e sucessos 
dos outros e ajudará a integração do 
país na tendência mundial para com- 
bater a dependência tecnológica no do- 
mínio da informática. 


A seguir, no segundo semestre de 
1975, trabalhadores de algumas em- 
presas ligadas à informática, especial- 
mente aquelas em que o Estado detém 
a maioria do capital como consequên- 
cia das nacionalizações dos grandes 
grupos financeiros, lançaram um mo- 
vimento de análise dos problemas do 
sector. 

As CT's de centenas de empresas 
produtoras ou utilizadoras de compu- 
tadores receberam um documento com 
uma breve análise da situação e a pro- 
posta de criação de uma Comissão des- 
tinada a elaborar um Plano Director 
para a informática. Após vários plená- 
rios, foi eleito um secretariado encar- 
regado de apresentar ao Governo, en- 
tão o VI GP, a proposta de criação de 
uma Comissão para o Plano Nacional 
Director de Informática, que teria uma 
composição mista:trabalhadores da in- 
formática e representantes do Governo. 


Esta, provavelmente, foi a primeira 


tentativa séria de dar uma forma orga- 
nizada ao tratamento dos problemas 
da informática de um ponto de vista 
nacional, apesar de todos os seus as- 
pectos controversos. Efectivamente, 
preferiu-se remeter as questões para 
uma Comissão Mista, sem se aprofun- 
dar a direcção que, do ponto de vista 
dos trabalhadores, deveriam seguir os 
trabalhos. Assim, correu-se o risco de 
pôr um grupo de trabalhadores a avali- 
zar, como representantes dos informá- 
ticos, medidas que poderiam não estar 
de acordo com os seus interesses. 

Na verdade, é necessário definir 
uma Política Nacional de Informática 
antes de se passar à fase de planifica- 
ção. Todos estes aspectos controversos 


acabaram por não amadurecer em vis- 
ta das “respostas” do(s) governo(s). 
Essa “resposta” é essencialmente. 
muito confusa mas, tanto quanto se 
percebe, caíu-se num daqueles impas- - 
ses habituais quando vários ministé- 
rios disputam o penacho da jurisdição 
sobre um dado assunto. 


(“Diário””, 19.7.77) 


CONFERÊNCIA DE 
TORREMOLINOS SOBRE AS 
ESTRATÉGIAS E AS POLÍTICAS 
EM INFORMÁTICA 


Com a aprovação do relatório e conclu- 
sões finais encerrou-se no passado 
dia 6 de Setembro no Palácio dos Con- 
gressos de Torremolinos a conferência 
SPIN—78, convocada pelo Director— 
—Geral da UNESCO, a fim de se dis- 
cutir as estratégias e políticas de infor- 
mática. 


Nesta conferência, durante dez dias, 
os delegados de 78 Estados membros 
da UNESCO entre os quais Portugal, 
além dos representantes e obsevado- 
res de organismos das Nações Unidas, 
organizações intergovernamentais e 
organizações internacionais trocaram 
experiências adquiridas em matéria de 
estratégias e de política de informática 
e propuseram vias e meios segundo os 
quais a informática pode contribuir pa- 
ra o desenvolvimento económico, so- 
cial e cultural dos países. 


Desde o início dos trabalhos verificou- 
-se uma divergência marcante entre o 
grupo formado pelos países industria- 
lizados e o grupo formado pelos países 
do Terceiro Mundo e em geral por to- 
dos aqueles que têm ainda uma fraca 
infraestrutura informática. 


Estes últimos solicitam com frequência 
a ajuda especial dos diversos organis- 
mos internacionais, nomeadamente 
através da criação de fundos que se- 
riam distribuídos pelas Nações Uni- 
das, a fim de poderem beneficiar o 
processo de desenvolvimento das 
técnicas informáticas e da sua utiliza- 
ção. 

Em contrapartida os delegados dos 
países desenvolvidos que dominam já 
estas técnicas estavam particularmen- 
te preocupados com as possíveis re- 
percussões na vida privada e na liíber- 
dade que pode ter uma má utilização 
dos computadores em geral e dos ban- 
cos de dados em particular. 
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Esta divergência foi particularmente 
realçada pelo Bangla-Desh e pela 
Suécia. Enquanto que o primeiro afir- 
mou que o seu país fracassou no plano 
económico precisamente pela falta de 
uma estrutura informática, a Suécia, 
por seu turno propôs formas de resol- 
ver os problemas que. a informática 
levanta especialmente no que se refere 
à liberdade e privacidade. 


Aprovadas uma série de recomenda- 
ções por consenso. o Director-Geral da 
UNESCO, no seu discurso final, re- 
conhecendo os riscos inerentes a uma 
má utilização da informática, não dei- 
xou de realçar que esses riscos podem 
desaparecer através de uma legislação 
apropriada e de convénios internacio- 
nais adequados, afirmando que: 


“A experiência na matéria dos 
países industrializados, prova que 
a informática, nascida do progres- 
so pode por sua vez acelerar o de- 
senvolvimento. 


Uma vez dominada pelos países 
em desenvolvimento estará em 
condições, mediante uma maior 
gestão dos recursos, de contribuir 
para reduzir a distância que os se- 
para dos países ricos. Por conse- 
guinte, inscreve-se dentro do pro- 
cesso iniciado para a procura de 
uma nova ordem económica inter- 
nacional”. 


A diversidade do equipamento informático existente em Portugal é fla- 
grante, o que reduz as suas possibilidades de expansibilidade e compatibili- 
dade. Os suportes de informação são os mais variados possíveis, desde o 
cartão perfurado de 80 e 96 colunas, até à fita de papel, a fita magnética e o 
disco. As linguagens utilizadas também são as mais diversas possíveis. 
Daí a dificuldade de integração do parque de computadores existente. Uma 
amostra dessa situação é o equipamento utilizado pelas autarquias locais: 


Marca e modelo Capacidade 

Serv. Mun. de Gondomar Bull-GE-58 SK 
Serv. Mun. Água 

e San. do Porto IBM S/3 16K 
Serv. Mun. Gás e Elec. 

do Porto IBM 8S/3/10 24K 
Serv. Mun. de V. Nova 

de Gaia IBM $/3/10 16K 
Serv. Transp. Colec. Porto IBM 8S/3/10 24K 
Serv. Mun. de Coimbra NCR C/100 16K 
Serv. Mun. de Estarreja Nixdorf 820/15 18K 
Serv. Mun. de Almada IBM 8S/3/10 16K 
Serv. Mun. de Oeiras IBM 370/125 160K 
Câm. Mun. de Lisboa IBM 360/20 8K 
Fed. Mun. 

do Dist. de Setúbal Philips P354 8K 
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CONFERÊNCIAS 
INTERNACIONAIS EM 1979 


4th Intern. Symposium on Computer 
System Modelling and perfo- 
mance evaluation 

29-31 Janeiro 1979, Viena (Áustria) 


9th International Symposium on Indus- 
trial Robots 
12-15 Março 1979, Washington (USA) 


4th GI Conference in Theoretical 
Computer Science 


"6-28 Março 1979, Aix-la-Chapelle 


(França) 


12th Simulation Symposium 
14-16 Março 1979, Tampa (USA) 


36th International Hardware Congress 
Junho 1979, Dublin (Eire) 


International Conference on Commu- 
nications 
10-13 Junho 1979, Boston (USA) 


6th Int. Colloquium on Automata, 
Languages an Programming 
16-20 Julho 1979, Graz (Áustria) 


Convenção Informática Latina 
5-6-7 Junho 1979, Barcelona 
(Espanha) 


9éme Conference IFIP sur les Techni- 
ques d'Optimisation 
4-9 Setembro 1979, Varsóvia (Polónia) 


Sth International Conference on Very 


Large Data Bases 

3-5 Outubro 1979, Rio de Janeiro 
(Brasil) 

Conference on Man — Machine 
Communication in CAO 
and CAM 


Outubro 1980, Kyoto (Japão) 


IFIP Congress 80 
6-9 Outubro 1980, Kyoto (Japão) 
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O PRESSÁGIO DE BABBAGE * 


1. INTRODUÇÃO 


A história conta, segundo uma das 
versões, que estando um dia Herschel 
e Babbage a conferir alguns cálculos 
astronómicos, Babbage, já irritado, 
disse: “Quem me dera que estes cál- 
culos podem ser feitos pelo vapor”. 
Ao que Herschel retorquiu: “É muito 
possível que isso venha a acontecer”. 

Torna-se interessante notar que 
Babbage pensou institivamente em 
termos do produto principal da tecno- 
logia do seu tempo, isto é, a energia do 
vapor. 

Faltando-lhe a tecnologia que pos- 
sibilitou os dispositivos electromecã- 
nicos, Babbage sofreu sucessivos ma- 
logros pois a necessidade das suas má- 
quinas, tanto do “Difference Engine” 
como do ““Analytical Engine”” não era 
muito importante na sua época visto 
elas não serem tão rápidas quanto 
se desejava. 

Algumas tentativas foram feitas 


para mostrar com que rapidez a pri- 


meira delas podia calcular. A primeira 
foi a construção de uma tabela a partir 
da fórmula X2+X+41. Para os pri- 
meiros números era possível, escre- 
vendo rapidamente, acompanhar a 
máquina, mas quando eram exigidos 
quatro algarismos a máquina era pelo 
menos igual em velocidade ao escri- 
tor... Como a máquina se podia fazer 
mover uniformemente por meio de um 
peso, o seu funcionamento podia man- 
ter-se durante qualquer duração de 
tempo. Poucas pessoas conseguiriam 
copiar com igual velocidade durante 
muitas horas consecutivas. 

Mas como veremos adiante, essa 
cadência de operação não era suficien- 
temente rápida para revolucionar a 
computação e foi uma das razões bási- 
cas que fez com que o seu trabalho 
passasse desapercebido. 

É bastante significativo que, tal 
como Lord Kelvin, também James 
Clerk Maxwell (ambos importantes 
cientistas seus contemporâneos) traba- 
lhassem naquilo que hoje conhecemos 

- como máquinas de calcular analógicas, 
e não em máquinas digitais como o fez 
Babbage e como o fazemos hoje em 
dia. 

Neste ponto será suficiente dizer 
que os físicos proeminentes do século 
dezanove se afastaram das ideias de 
Babbage e voltaram-se para tipos de 


máquinas que eram voltadas para o 
cálculo analógico de equações diferen- 
ciais e realizáveis na prática apenas 
com a tecnologia da época. Parece bas- 
tante verosímil que eles, como físicos, 
tenham compreendido melhor os pro- 
blemas de engenharia que se punham 
do que o matemático Babbage. [ 

Vale, entretanto, a pena notar que 
o espanhol Torres Quevedo (1852- 
-1936) propôs em 1893 uma solução 
electromecânica para as ideias de Bab- 
bage. A sua máquina pode ser encara- 
da como um passo, ainda que fugaz, 
na cadeia do desenvolvimento dos 
dispositivos digitais. 


2. UMA QUESTÃO DE TABELAS 


Vimos já que os astrónomos 
tinham um interesse substancial por 
tabelas exactas assim como uma gran- 
de necessidade delas. Além disso já vi- 
mos como esta necessidade pesa como 
motivo no trabalho de Babbage; de 
facto tem perdurado até aos tempos 
modernos, tendo fornecido grande 
parte do incentivo para a construção do 
primeiro computador. Isso porque os 
calculadores analógicos dão poucos re- 
cursos ao astrónomo. A sua necessida- 
de são tabelas sem erros com uma 
exactidão que transcende-a conseguida 
por máquinas tais como o analisador 
diferencial, e que só pode ser obtida 
pelas máquinas do tipo digital, a pri- 
meira e mais simples das quais é 
o ábaco. 

O sueco, Pehr Georg Scheutz 
(1785-1873), construiu em 1834 um 
“Difference Engine” inspirado nas 
ídeias de Babbage e com considerável 
ajuda deste. Em 1851 a Academia Sue- 
ca deu fundos a Georg Scheutz para 
construir uma versão maior e mais 
aperfeiçoada, que foi completada em 
1853. Foi trazido para Londres e pouco 
tempo depois exibido na Grande Exibi- 
ção de Paris em 1855, onde ganhou 
uma Medalha de Ouro. 

É curioso notar que Scheutz foi 
muito afortunado ao construír as 
suas duas máquinas e Babbage não o 
foi. Talvez tenha sido devido ao facto 
de Scheutz ter começado com um mo- 
desto protótipo, ter demonstrado a sua 
viabilidade, e só então ter prosseguido 
para um maior e mais útil instrumen- 
to. Talvez também tenha só sido uma 
questão de temperamento. 
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DIFFERENCE ENGINE á 


Para descrever o “Difference En- 
gine” de Babbage precisamos primei- 


ro de fazer uma breve referência às ta-. 


belas — o que são e porque são ou fo- 
ram importantes. Desde o tempo de 
Leibniz e Newton os matemáticos e, de 
um modo geral, os que eram, nesses 
tempos, mais conhecidos como ““filó- 
sofos naturais” estavam muito interes- 
sados na produção de tabelas tanto no 
que toca a cálculos matemáticos como 
É o caso com as tabelas de multiplica- 
ção, de logaritmos, de senos e cose- 
nos, etc., como ainda nas observações 
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e medições físicas. Ambos os tipos de 
tabelas são os recursos pelos quais os 
cientistas aprenderam, desde há muito 
tempo, a registar as suas experiências 
de modo que outros possam beneficiar 
delas. 

Quando as tabelas são produzidas 
em termos de vários princípios mate- 
máticos como no caso da tabela de lo- 
garitmos, a experiência diz que os se- 
tes humanos cometem muitos erros, e 
isto foi uma das razões básicas da irri- 
tação de Babba:- = Herschel com as 
pessoas que as faziam. Foi sem dúvida 
a ideia de trocar pessoas “'falíveis”” por 
uma máquina “infalível” que surgiu a 
Babbage nesse momento. 

Vale a pena acentuar neste ponto 
que a sua primeira máquina estava 
muito especializada na sua função e 
não podia ser, de modo algum, descri- 
ta como um instrumento de aplicação 
geral. Só tinha um programa ou tarefa 
que podia levar a cabo, apesar de com- 
plexa. 

Pode ser encarada como uma ten- 
tativa, na realidade brilhante, para 
automatizar um processo específico, 
mais do que um ensaio para automati- 
zar a matemática numérica. 


3. O TEAR E O COMPUTADOR 


Em 1833, durante um hiato no de- 
senvolvimento do “Difference Engi- 
ne””, Babbage concebeu o seu “chef 
d'oeuvre””, a sua “Analytical Engi- 
ne”. Pretendia ser, em teoria, um 
computador de aplicação geral, quase 
no sentido moderno dessa expressão. 

Essa máquina seria a meta da sua 
vida, e trabalhou nela até à morte, em 
1871. 

A ideia base desta máquina era to- 
talmente diferente da do “Difference 
Engine”. Nesta nova máquina ele viu 
claramente algumas das ideias que ca- 
racterizam o computador moderno. 
Surgiram-lhe algumas dessas ideias 
após observar o tear de Jacquard, que 
revolucionou a indústria têxtil em 
1803. 

A chave do invento de Jacquard é 
o uso de uma série de cartões perfura- 
dos de modo a apresentarem o padrão 
desejado. Os furos permitem que gan- 
chos subam e puxem para baixo os 
fios, de maneira a que, quando a lan- 
çadeira passa por eles vá por cima de 
certos fios predeterminados e por bai- 
xo dos restantes. 

Será talvez interessante ler o que 
Babbage disse acerca do tear de 
Jacquard: 

“É um facto conhecido que o tear 


de Jacquard é capaz de tecer qualquer 
desenho que a imaginação do homem 


possa conceber...” 
Os furos são perfurados num con- 


junto de cartões de modo que quando 
esses cartões são colocados num tear 
de Jacquard, ele tecerá então... o pa- 
drão desenhado pelo artista. 

Ora o tear pode usar fios que se- 
jam todos da mesma cor; suponhamos 
que são fios por branquear ou mesmo 
brancos. Nesse caso o pano será tecido 
todo de uma só cor; mas haverá um 
padrão adamascado sobre ele tal como 
o artista o desenhar. 

Mas o tecedor pode usar os mes- 
mos cartões e colocar no tear fios de 
qualquer outra cor. Cada fio pode até 
ser de cor diferente, ou de diferente 
tom; mas em qualquer dos casos a for- 
ma do padrão será precisamente a 
mesma — só diferindo as cores. 

A analogia com o “*Analytical 
Engine””, deste conhecido processo, é 
quase perfeita. 

O “Analytical Engine”” consiste 
em duas partes: 

“1.º — O armazém no qual todas as 
variáveis para serem operadas con- 
juntamente assim como todas as 
quantidades provindas dos resultados 
de outras operações são colocadas. 

2.º — O moinho ao qual as quanti- 
dades prontas para serem operadas 
são constantemente levadas. 

Cada fórmula que seja necessária 
ao “Analytical Engine” para compu- 
tar, consiste em certas operações 
algébricas a serem efectuadas sobre 
letras correspondentes a variáveis da- 
das, e de certos posicionamentos 
dependentes do valor numérico 
designado por essas letras. 

Existem, por conseguinte, dois 
conjuntos de cartões, o primeiro para 
reger a natureza das operações a 
serem efectuadas — chamados cartões 
operacionais — o outro para reger as 
variáveis particulares nas quais esses 
cartões são solicitados a operar — sen- 
do estes últimos designados por car- 
tões variáveis. Ora o símbolo de cada 
variável ou constante é colocado no 
topo de uma coluna capaz de conter 
qualquer número de dígitos reque- 
ridos. 

Com esta disposição, quando qual- 
quer fórmula é solicitada para ser com- 
putada, um conjunto de cartões opera- 
cionais deve ser enfiado, o qual 
contém a sequência de operações se- 
gundo a sua ordem de ocorrência. 
Outro conjunto de cartões deve então 
ser enfiado, para mandar as variáveis 
para o moinho, segundo a ordem espe- 
cificada. 


Cada operação requer outros três 
cartões, dois para representar as variá- 
veis e constantes e os seus valores 
numéricos, sobre o qual o cartão ope- 
racional prévio vai actuar, e um para 
indicar a variável na qual o resultado 
aritmético da operação deve ser colo- 
cado. 

O “Analytical Engine” é, no en- 
tanto, uma máquina de natureza muito 
geral. Qualquer que seja a fórmula 
requerida para calcular, a sequência 
do seu cálculo deve ser-lhe comuni- 
cada por dois conjuntos de cartões. 
Quando estes estiverem colocados, o 
dispositivo torna-se especial para 
esta fórmula particular. 

Cada conjunto de cartões feito 
para uma dada fórmula poderá . em 
tempo posterior, recalcular are, 
fórmula, com as constantes que fortm 
requeridas. 

Assim o Analytical Engine possui- 
rá uma biblioteca própria. Qualquer 
conjunto de cartões já feito poderá re- 
produzir futuramente os cálculos para 
o qual ele foi primeiramente concebi- 
do. O valor numérico das suas constan- 
tes pode, então, ser inserido. 

Lady Lovelace, uma das raras pes- 
soas que compreendeu profundamente 
o trabalho de Babbage na sua época, a- 
firmou: “Podemos dizer com proprie- 
dade que o Analytical Engine tece pa- 
drões algébricos tal como o tear de 
Jacquard tece flores e folhas.”” 
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CENTROS DE INFORMÁTICA 


CAMINHOS DE FERRO PORTUGUESES 


1. INTRODUÇÃO 

Os Caminhos de Ferro Portugue- 
ses — EP, têm actualmente cerca de 
27 000 trabalhadores dispersos pelos 
mais variados sectores. Face a uma 
empresa de tal dimensão, e para que a 
mesma corresponda às solicitações e 
anseios duma empresa virada ao futu- 
ro e às técnicas avançadas, é sem dúvi- 
da o Centro de Informática o orgão 
central dessa mesma estrutura. 


2. CONFIGURAÇÃO 


A composição do Centro de Infor- 
mática da CP distribui-se por: 


2.1. ORDENADORES 


2.1.1. SISTEMA IBM 

— 1 ordenador 370/135 com 144K 
de memória 

— 5 unidades de banda 3420 

— 6 unidades de disco 2319 

— 1 leitor de cartões 2501 

— 1 impressora 1403 - 1100 linhas/ 
/minuto 


2.1.2 SISTEMA BULL 


— 1 ordenador GAMA 115 com 8K 
de memória 

— 4 unidades de banda de 7 pistas 

— 1 impressora de 60 linhas/ minu- 
to LS600 


— 1 perfurador de cartões CPZ 101 
— 1 leitor de cartões 


2.2. RECOLHA 


2.2.1. SISTEMA CMC - Modelo 8 


— 1 unidade central de 8K de me- 
mória 

— 2 unidades de banda (1 de 7 pis- 
tas de 800/556 BPI e 1 de 9 pistas de 
1600 BPI) 

— 1 unidade de disco de 7 milhões 
caracteres 

— 20 teclados modelo 105 

— 1 teletipo modelo TTY 33 


2.2.2. SISTEMA IBM 


— 1 perfuradora modelo 029 


2.2.3. SISTEMA BULL 


— 1 perfuradora/verificadora mode- 
lo PERFORA TRIKEK 212 


2.2.4. SISTEMA SINGER 


O parque 1.C.L.(antigo Singer), ins- 
talado na C.P. é distribuido por: 
CIN — Centro de Informática 


CRRD — Porto 
CRRD — Lisboa: Centros Regionais 
de Recolha de dados 


CRRD — Barreiro 

é constituído por 

— 4ICL 1501 - 8K 

— 23 ICL 1501 - 4K 

— 4 conversores (800 bpi - 7 pistas) 

— 4 impressoras mod. 1551S 

— 4 adaptadores de teletransmissão 
mod. 1535 


3. ORGANIZAÇÃO 
O CIN (Centro de Informática da 
C.P.) tem ao seu serviço 114 trabalha- 
dores, assim classificados: 


3.1. CHEFIA 


— 1 chefe de Centro 

— 1 chefe de Serviço de Análise de 
Sistemas 

— 1 chefe de Serviço de Exploração 
de Ordenadores 

— 1 chefe de Serviço de Controlo e 
Recolha de Dados 


3.2. O Serviço de Análises de Sis- 
temas é composto por 15 trabalhado- 
res: 


— 7 analistas 

— 5 programadores 6IBM) 

— 3  analistas/ programadores 
(BULL) 


3.3. Oserviço de Exploração de Ur- 


denadores é composto por 6 trabalha- 
dores. 


Gonçalves Filipe 


3.4. O Serviço de Controlo e Reco- 
lha de Dados é composto por 52 traba- 
lhadores distribuídos por: 

— 5 trabalhadores na Recepção e 
expedição 

— 47 trabalhadores na perfuração/ 
/verificação/gravação 


3.5. Existe também um Serviço 
Administrativo composto por 13 traba- 
lhadores e que serve de apoio à chefia. 


3.6. Existe igualmente um Sector 
de Estatística com 15 trabalhadores 
distribuídos por: 


— 11 trabalhadores no controlo 
técnico 

— 4 trabalhadores no gabinete 
técnico de estatística 


3.7. O horário de trabalho é de 40 
horas semanais (repartido por 5 dias 
de trabalho), para os trabalhadores da 
Chefia e Analistas (9H/13H-14H/18H) 
e de 36 horas semanais (igualmente re- 
partidas por 5 dias) para todos os ou- 
tros trabalhadores — com excepção da 
Mecanografia — centro de Controlo e 
Recolha de Dados. Os trabalhadores 
do sector de Controlo e Recolha (perfu- 
ração/verificação/gravação) têm o se- 
guinte horário: 

1.º turno: 07H20/14H20 

2.º turno: 13H50/20H50 


NOTA: Face às novas técnicas de auto- 
matização e para que a empresa pos- 
sa corresponder às necessidades 
dum Caminho de Ferro moderno, e 
necessariamente, ao serviço da po- 
pulação, o Centro de Informática da 
C.P. terá a partir de Janeiro de 1979 
uma nova constituição do seu equi- 
pamento de Hardware visando, com 
a substituição, corresponder a uma 
melhor descentralização dos diver- 
sos sectores e empreender novas im- 
plantações informáticas face às ne- . 
cessidades existentes. 

Assim, todo o equipamento exis- 
tente (BULL e IBM) será substituído 
por equipamento UNIVAC, cuja con- 
figuração a seguir se descreve. 
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CAMINHOS DE FERRO PORTUGUESES Sistema Virtual 90/60 — Sistema Central 


CIN 
SPERRY UNIVAC 90/50 
RAE Tsçã , op E PROCESSADOR MEMÓRIA CANAL 
MICROPROGRAMADA o] MOCTIPLEXER 
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SELECTOR 2 
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CONTROLADOR 


PROCESSADOR 


DE TELECOMUNICAÇÕES 


REDE DE TELECOMUNICAÇÕES 


AM. 
CAMAHHOS, E, Ás a PORTUGUESES REDE DE TELEPROCESSAMENTO 
SISTEMA CENTRAL 
UNIVAC 90/60 
reL PROCESSADOR Bi oi 
O | so Met DE = 
TELECOMUNICAÇÕES EA DEM (CONEXÃO LOCAL) 


MODEM 

INTERACIIVO-7IME SHARING 
UTILIZANDO IMS 

LOCAL 

VER CONFIGURAÇÃO ANEXA 


CONCENTRADOR DE DADOS 


O:»---T[lo 


UNIVAC PROGRAMAÇÃO - CIN 


Da. 24 a] e: e 
ES 


CDUQUE CLDUQUE STA. ApReiuna STA. APOLÓNIA STA. APOLÓNIA 
EDIF ADMIMST. EME ADMUSL ENE ' PESSOAL RA 0 ESTAÇÃO EDIF. D. ABASTECIMENTOS 
51 


Eis 3º ANDAR 


4. SUBSTITUIÇÃO DE 
EQUIPAMENTOS 


O Sistema CP-UNIVAC é o conjun 
to de Hardware-Software necessário 
para satisfazer as carências informáti- 
cas da CP. 

O Sistema existe no âmbito de um 
programa — coiaboração entre a 
SPERRY-UNIVAC e a CPj Para a sua 
instalação e implementações iniciais 
definiu-se um projecto, com os seguin- 
tes objectivos: 


1) Substituiço * equipamento 
“IBM” sem alteração notável das roti- 
nas a passar actualmente no 370/135 
DOS/VS (do ponto de vista da análise). 

11) Substituição do equipamento 
“Bull” com conversão dos programas 
escritos em “TAB” para “COBOL”. 

iii) Implantação da rede de tele- 
processamento (V.secção 2). 

iv) Formação dos membros do 
*““CIN” para utilização do 90/60 - VS/9 
e exploração da rede de teleprocessa- 
mento. 

v) Implementação de “IMS”/90 
utilizando ' UNIQUE”, nas funções de 
abastecimentos, pessoal e contabilida- 
de. 


vi) Instalação do UTS400 na Direc- 
ção Financeira, formação sobre a pro- 
gramação e conexão ao 90/60 na fun- 
ção de contabilidade. 

vii) Estudo da implantação de apli- 
cação utilizando o DMS. Monitoragem 
de desenvolvimento. 

5. EVOLUÇÃO DO SISTEMA 

CP - UNIVAC 


A C.P. elaborou um plano infor- 
mático para o período de 79/83 que 
sob o ponto de vista informático se ba- 
seia na utilização de Bancos de Dados 
e do Teleprocessamento. 

Em resumo, salientemos algumas 
áreas de evolução do sistema. CP- 
- UNIVAC. vÊs 

l. Formação de um Banco de 
Dados para a função pessoal e outro 
para a função abastecimentos. 

Formação iniciada já no âmbito do 
projecto CP - UNIVAC. 

2. Desenvolvimento de um siste- 
ma de Reserva Automática de Luga- 
res. 

3. Ligação dos ICL 1500 dos 3 
centros de recolha ao sistema central 
VS/9. 

Actualmente, o projecto CP - 
- UNIVAC engloba uma ligação local. 


CAMINHOS DE FERRO PORTUGUESES 


CIN 


EMISSÃO 
DE 


FICHAS E DOCUMENTOS 


INFORMÁTICA 


MEMÓRIA 


24 KB 


IMPRESSORA 


200 CPSs 


4. Disseminação de outros termi- 
nais para time-sharing. 

5. Implementação do package 
UNIS com recolha de dados no local 
(badge cards). Solução possível com a 
utilização do V 77. 

Os utilizadores seriam os grupos 
oficinais da C.P. situados no Barreiro, 
Entroncamento e Campanhã. 


6. Sistema de encaminhamento 
de vagões. Sistema que estará condi- 
cionado ao sistema de tomada de da- 
dos. Sistema em tempo real previsto 
para 83. 


O anteprojecto do plano informáti- 
co para o periodo de 1979/83 e os pon- 
tos salientados anteriormente permiti- 
rão um upgrade a 3 anos (memória, 
discos e terminais) do sistema VS/9 ou 
uma necessidade de instalação de ou- 
tro sistema VS/9. 


O êxito desta evolução, além de- 
pender do projecto CP-UNIVAC referi- 
do neste relatório, dependerá forte- 
mente de uma política de formação pa- 
ra todo o pessoal da C.P. 


* SISTEMA PARA A DIRECÇÃO FINANCEIRA 


2X DISKETTES 


MICROPROCESSADOR 


UTS 406 


MASTER 


SISTEMA VIRTUAL 90/50 
UTILIZAÇÃO. DO INS/96 
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Data Modul 


Cassetes Digitais. 
Qualidade de fita 
computadora. Cinco 
tipos diferentes. 


Floppy Disc. 
Graváveis nas duas 
faces. E em caixa 
arquivo. 


Banda Computadora. 
Testadas a 6.250bpi. 
Em ring-automático, 
tape-seal ou caixa. 


BASF é o maior forne- 
cedor europeu de supor 
tes magnéticos para 
computadores. 


Fabricamos tudo de 
harmonia com o s/sis- 
tema e rentabilidade. 


Dispomos de 25 modelos 
diferentes de "Disc- 
-Packs" para todos os 
tipos de drives. 


Um deles será o seu! 
Informe-se!! 


LISBOA 
R. de Sta. Bárbara, 46-50 
Telef. 562511 - Apartado 1438 
Telex 12219 e 16742 


PORTO 
R. Manuel Pinto de Azevedo, 626 
Telef. 692061 

Telex 22753 - Apartado 259 BASF - PROGRAMADA PARA O FUTURO!! 


1. APRESENTAÇÃO 


“Bases de Dados” é um conjunto de técnicas, predominantemente ““software””, para a gestão de uma massa, geralmente 
grande, de dados partilhados por vários utilizadores. 

Os “'packages”' destinados a gerir esses dados — Sistemas de Gestão de Bases de Dados (SGBD) — asseguram sempre 
um certo número de funções que são: 

— armazenamento e estruturação dos dados 

— controlo de confidencialidade 

— regulação da concorrência 

— preservação da integridade 

Tais SGBD diferem, no entanto, quanto à implementação de tais funções e sobretudo quanto à estruturação dos dados e às 
linguagens utilizadas para definir tal estrutura ou aceder a esses dados. 

Costuma-se classificar os SGBD comercializados em duas categorias: 

— hierárquicos 

— em rede 

segundo o tipo de estrutura empregada. 


- Aestes 2 tipos, vem recentemente juntar-se os SGBD relacionais, sistemas baseados em novos conceitos de manipulação dos 
dados e que ainda não foram comercializados mas contam com um grande número de protótipos já implementados. 
À apresentação que se faz a seguir dos Sistemas de Gestão de Bases de Dados consta de 3 partes: 
1.º — introdução aos sistemas de Bases de Dados (Veith) 
a — apresentação de 2 tipos de SGBD (Sales e Barbosa) 
— descrição duma aplicação dos SGBD ro dominio de Informática Cientifica e Técnica (Lucas), e proposta duma lin- 
guagem para a manipulação de Bases de Dados Estatisticos (Sernadas). 
Seria desejável que, em número futuro, os profissionais no domínio das Bases de Dados apresentem outras aplicações, que 
cubram outros aspectos mais correntes na Informática Portuguesa. O modelo hierárquico será apresentado no próximo número 
da revista. 


2. UM EXEMPLO DE APLICAÇÃO 


Consideremos um ficheiro de pessoas e um ficheiro de 
veículos. Suponhamos que possuímos para cada pessoa 
as seguintes informações: 


— Código-pessoa 

— Nome, nome prónrio 

— Ano de matrícula 

Matrícula do automóvel 

— Marca nvezes 
— Potência 


Consideremos ainda que se pretendem fazer os dois 
tipos de perguntas: 


A — Quais são os automóveis da pessoa X? 
B — Quem é o proprietário do automóvel Y? 


Evidentemente, que na resposta às perguntas anterio- 
res deve ser indicado para cada objecto-resposta as suas 
características existentes no ficheiro (por ex.: para o pro- 
prietário de um veículo o seu código-pessoa, nome, nome 
próprio e data de nascimento). 
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2.1. Solução clássica 


Admitindo que o código-pessoa identifica univoca- 
mente uma pessoa, e matrícula identifica univocamente um 
automóvel, uma solução possível seria a constituição de 
dois ficheiros e uma tabela como se segue: 


- Ficheiro de pessoas 


Cada registo conterá: 
— Código-pessoa 
— Nome, nome próprio 
— Ano de nascimento 


Ficheiro de veículos 


Cada registo será constituído por: 
— Matrícula 
— Marca 
— Potência 
— Código-pessoa de proprietário 


Tabela (a manipular em memória) 


Contará para cada código-pessoa o número de veículos 
que a pessoa correspondente possui, seguido das matrícu- 
las desses veículos. Esta solução, escolhida com a finalida- 
de obter um tempo razoável de resposta às perguntas atrás 
enunciadas, tem entre outros, os seguintes inconvenientes: 


— Redundância das informações 
Por exemplo, o código-pessoa é repetido 3 vezes: no 
ficheiro das pessoas, no ficheiro dos veículos e na Tabela. 


— Necessidade de modificação dos ficheiros e dos pro- 
gramas 


Quando se pretender outro tipo de pesquisa, por exem- 
plo, aceder às pessoas através do ano de nascimento. 


2.2. Solução base de dados 


Numa tal solução, devem ser dissociadas as duas enti- 
dades em causa: pessoas e veículos. Ter-se-á também de 
prever, ao nível de definição da estrutura, a relação 1 n 
entre pessoas e veículos e 1 1 entre veículos e pessoas 
(partindo da hipótese que um veículo só pode ter um pro- 
prietário). 

Automóveis e pessoas estarão ligados logicamente 
através de apontadores, diminuindo a redundância aponta- 
da na solução clássica. 

Se se pretender, em dada altura, aceder às pessoas 
através da data de nascimento, não será necessário reestru- 
turar a base de dados: será necessária a criação de um fi- 
cheiro inverso” sobre os anos de nascimento, sem ter para 
tal de reestruturar a base. É contudo necessário indicar aos 
programas que manipulam a base este novo tipo de acesso. 
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NOTA: 


Evidentemente, não se pode, na solução base de dados, 
falar em independência total dos dados em relação aos pro- 
gramas. É no entanto importante que se diga que este es- 
tado de coisas é devido a uma insuficiência da técnica e, 
em nosso entender, a evolução será no sentido da referida 
independência. 

Em contrapartida, constatámos que não é necessário 
reorganizar a base, e que a implantação de um novo ca- 
minho de acesso não suprime os que já foram definidos. 

Como é sabido, existem vários SGBD comercializados 
usando modelos de dados diferentes (por exemplo: hierár- 
quico, rede, relacional). Não pretendemos, neste pequeno 
exemplo, pensar em nenhum em especial e queremos tam- 
bém ressalvar que a solução preconizada para criar um novo 
tipo de acesso não é possivel em todos os modelos comercia- 
lizados. Cremos, contudo, que a evolução deste domínio 
permitirá cada vez maior possibilidade de modificação de 
estrutura dos dados (até integração de bases de dados, 
porque não?) e maior independência dos programas em 
relação aos dados que manipulam. 
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O PORQUÊ E OS REQUISITOS DUMA BASE DE DADOS | 


nota do tradutor 


O aparecimento de qualquer nova 
técnica de gestão da informação, pro- 
voca, em' quem tem por profissão tal 
gestão — sobretudo quando efectuada 
por meios informáticos — uma curiosi- 
dade imediata, uma tentdtiva de apre- 
ensão do-seu funcionamento e, se ele 
corresponde à resolução dos proble- 
mas diariamente sentidos, sonhar com 
“o dia em que... 

Eis o que sucedeu decerto com as 
Bases de Dados. 

Porém, se tal dia surge e os fornece- 
dores são vários, o problema da esco- 
lha obriga necessariamente a, um co- 
nhecimento mais perfeito não só do 
que é oferecido, mas também do que 
se pretende. 

O artigo que a seguir se apresenta, 
da autoria de FRANK H. VEITH, JR., 
da CINCOM SYSTEMS, INC., e subor- 
dinado ao título “O porquê, e os requi- 
sitos duma Base de Dados", parece- 
-nos servir como boa base para iniciar 
tal estudo. E, se o dia ainda não che- 
gou, espera-se que pelo menos a curio- 
sidade saia diminuída. 


F.D.Silva Neves 


1. A compreensão da gestão de Ba- 
ses de Dados, implica o exame da evo- 
lução do processamento da informação, 
até ao aparecimento da necessidade da 
sua existência. 

Para tal, vamo-nos socorrer duma 
via analógica. 

Recuemos 12 a 15 anos e considere- 
-se uma companhia sem departamen- 
to EDP. Mais precisamente o seu De- 
partamento de Encomendas. Assiste- 
-se aí ao processamento das encomen- 
das, efectuado por empregados de es- 


critório, os quais elaboram as facturas - 


e actualizam os ficheiros de clientes e 
de existências. Quaisquer relatórios 

. analíticos são extraídos manualmente 
de tais ficheiros — o que limita consi- 
deravelmente a sua frequência — e o 
seu tempo de resposta encontra-se for- 
temente dependente da complexidade 
dos cálculos solicitados. 

Certo dia, é proposta ao chefe de 
tal departamento a automação do pro- 
cessamento da informação, a qual lhe 
permitiria obter as seguintes vanta- 


gens: diminuição dos custos com o 
pessoal, melhor prestação de serviço 
aos clientes, contabilização dos movi- 
mentos mais perfeita e, finalmente, re- 
latórios mais amiudados e mais com- 
pletos. “ 

Após um aturado trabalho de per- 
suação, acaba por ceder. 

“departamento EDP, entretanto 
fundado, envia os seus analistas para 
proceder ao exame do sistema, e ini- 
cia-se o diálogo. 

Todavia. “istas conhecem mal 
o servis - -utado pelo Departamen- 
to e os funcionários deste nada sabem 
acerca do processamento automático 
da informação. O desenho do sistema 
acaba por ser elaborado pelo analista 
de sistemas, com base nos elementos 
que o pessoal do departamento preten- 
de que constem dos vários estados im- 
pressos. 

Seguiram-se as fases de programa- 
ção, de conservação dos ficheiros para 
suporte mecanográfico e, de imple- 
mentação, que acabaram por resultar 
num dispêndio de esforço bastante su- 
perior ao inicialmente previsto e que 
se prolongaram para além do projecta- 
do. 

Após o arranque do sistema o pes- 
soal de departamento verificou 
que deixou de ter acesso a determina- 
da informação, e que não informou su- 
ficientemente o analista acerca de de- 
terminados pontos. 

É indispensável uma relação diária 
de encomendas por ordem do cliente”. 
Nova necessidade de programar, de 
efectuar algumas alterações nos pro- 
gramas já existentes, de criar um novo 
ficheiro e de sobrecarregar os tempos 
de processamento. 

Acaba por se constatar que o pessoal 
do departamento não elaborava ante- 
riormente tal diário. Porque será ele 
actualmente necessário? Simplesmen- 
te porque podia, para responder a uma 
pergunta dum cliente, manusear o fi- 
cheiro dos clientes e encontrar aí toda 
a informação necessária. 

“E indispensável uma relação diária 
de encomendas por produtos”'. Nova- 
mese, porquê? Simplesmente porque 
cro possível verificar para determina- 
do produto, quais as encomendas não 
satisfeitas, por mera inspecção do fi- 
cheiro dos produtos. 


Frank H. Veith, Jr 
Cincom Systems, Inc. 


Eis os primeiros sintomas do sindro- 
ma das listagens. Seguem-se as cata- 
dupas de pedidos de listagens, para 
servir as necessidades (ou os desejos?) 
de informação do departamento, as 
quais se encontram: em mutação per- 
manente e, para suprir as deficiências 
da análise inicialmente elaborada. 

Ao longo do tempo. este mesmo pro- 
cesso é repetido na automação do pre- 
cessamento da informação de outros 
departamentos, arrastando a necessi- 
dade de transformar os ficheiros ma- 
nuais em mecanográficos. Assiste-se 
então ao aparecimento de vários fichei- 
ros de Clientes: um para o processa- 
mento de encomendas, outro para 
Contas Correntes, outro para o depar- 
tamento de Vendas, etc. A carga resul- 
tante sobre o equipamento EDP au- 
mentou para além do esperado. O nú- 
meto de programadores de manuten- 
ção aumentou. Os custos do departa- 
mento EDP subiram em flecha. Aa- 
quisição de equipamento não era reali- 
zada em tempo. O serviço prestado aos 
vários departamentos entrou em fase 
de degradação. 


“É necessário fazer alguma coisa”, 
exclamou o pessoal do departamento 
EDP. “E necessário promover a reco- 
lha de dados no lugar próprio onde têm 
origem”. E o aparecimento de tal tipo 
de recolha não tardou. 


“É necessário resolver o problema 
deste relatório”. E contratam-se espe- 
cialistas. “É necessário reduzir as lis- 
tagens””. E introduziu-se o teleproces- 
samento. 


Quando se tornou necessário resol- 
ver o problema da cópia da imensa 
quantidade de ficheiros existentes em 
banda magnética para disco, para per- 
mitir o tempo real, a surpresa foi total. 
Ficou a descoberto o segredo dos pro- 
cessamentos em lotes: a enorme dupli- 
cação de informação existente nos fi- 
cheiros. - 


Era impossível conseguir colocar em 
suporte de acesso directo tal volume 
de informação redundante. 


Realizou-se um trabalho de consoli- 
dação de ficheiros, o qual implicou a 
resolução do problema da superação 
de divergências existentes entre de- 
partamentos, acerca da informação 
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que lhes era comum. E novo trabalho 
de programação. Entretanto, compre- 
endeu-se que a informação viajava a- 
través dos vários departamentos, o 
que foi tomada como pista para a reso- 
lução do problema. Qualquer cliente 
deveria ser tomado como uma entida- 
de únita, e não como se dum diferente 
se tratasse, para cada departamento. 
A necessidade de manter a informa- 
ção em acesso directo, provocou o de- 
senvolvimento de novos e ais com- 
plexos processos de organiz ào de da- 
dos. Não é possível dar resposta a uma 
pergunta efectuando uma busca se- 
quencialmente. Verificou-se que no 


processamento em lotes a mesma tran-.. 


sacção era processada em ordem a per- 
mitir que nos vários ficheiros os ele- 
mentos de informação duplicados fos- 


sem actualizados e ficassem portanto . 


em conjugação. Não era possível em 
tempo real fazer face a tal volume ex- 
tra de processamento. Era absoluta- 
mente imperioso determinar quais as 
inter-relações existentes entre os vá- 
rios ficheiros para permitir o desenvol- 


vimento de algoritmos de decisão mais 
complexos, e para tornar o processa- 


mento de dados mais orientado para o 

» planeamento e o controlo retirando-lhe 
o simples carácter de histórico que ti- 
nha até então. 

Também se constatou que a infor- 
mação dentro duma organização cons- 
tituio seu mais importante activo. Que 
é independente e desligada das fron- 
teiras quer dos departamentos quer 
das aplicações. Que é ainda indepen- 
dente do processo de input escolhido 
ou da forma como é apresentada. À in- 
formação deveria ser gerida por uma 
função independente utilizando um 
também independente sistema de apli- 
cação. Antes de prosseguir, tentemos 
dar uma ampla definição de Base de 
Dados (DATA BASE). 

Uma Base de Dados é um repositó- 
rio ou um acerto de toda a informação 
necessária a uma organização. No limi- 
te, cada pedaço de informação será ar- 
mazenada uma só vez, eliminando a 
duplicação existente nos métodos de 
trabalho tradicionais. 

Toda a informação necessária a uma 
duplicação esté imediatamente dispo- 
nível, e será possível a várias aplica- 
ções partilhar a informação comum. 
Como consequência, desde que a in- 
formação seja rodificada por uma a- 
plicação, fica imediatamente disponi- 
vel para as outras, na sua forma mais 
actual. Deixa de ser necessária a trans- 
ferência de dados de um ficheiro para 
outro. E finalmente, a associação dos 
dados existen'es num conjunto de fi- 


= 


cheiros inter-relacionados ou mesmo 
integrados é mais eficientemente con- 
seguida, ainda que cada um deles con- 
tinue a conservar a sua independência. 

O conceito de base de dados é relati- 
vamente simples, mas os problemas 
levantados e os condicionalismos im- 
postos pela sua gestão são extrema- 
mente complexos e não são fáceis de 
adivinhar. Um Sistema de Gestão de 
Base de Dados (DATA BASE MA- 
NAGEMENT SYSTEM — DBMS) con- 
cebido com rigor, deverá antes de mais 
permitir que o utilizador implemente 
com rapidez e sucesso uma “'versão 
inicial”” da Base de Dados a qual servi- 
rá de ponto de partida para um sistema 
integrado de gestão da informação. 

Contudo, a ansiedade de escapar 
aos problemas dos processamentos 
tradicionais e de conseguir dispor do 
potencial inerente à utilização duma 
Base de Dados tem sido responsável 
pela elaboração de ''versões”” iniciais 
tão deficientes que acabam por compli- 
car ainda mais o problema, em vez de 
o atenuarem. 

Por estas razões, a experiência indi- 
ca que o desenho do Sistema de Gestão 
de Base de Dados, para permitir evitar 
no futuro os becos sem saída do passa- 
do, deve obedecer aos seguintes pará- 
metros: 


— Adequação a todas as necessida- 
des quer da armazenagemquer do 
processamento de dados; 

— Independência da informação ao 
nível de elemento ou campo; 

— Controlo severo da redundância; 

— Capacidade ilimitada e flexível de 
associação ou relacionação da in- 
formação; 

— Segurança e integridade da Base 
de Dados; 

— Independência em relação ao am- 
biente; 

— Independência em relação ao e- 
quipamento e à linguagem; 

— Rendimento óptimo e eficiência 
em todos os casos; 

— Facilidade nas fases de conversão 
ou transição. 


Cada um dos parâmetros indicados é 
por si só crítico, e entre todos verifica- 
-se a existência duma interdependên- 
cia apertada. Cada um deles é indis- 
pensável, e a ausência dum só pode a- 
fectar seriamente a valia dos restan- 
tes. Por exemplo, se não existir uma 
protecção interna segura e eficaz da 
própria Base, qualquer um dos outros 
pontos passa a ter um valor meramen- 
te marginal. 
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2. O sistema de gestão duma base de 
dados deve permitir todas as neces- 
sidades de armazenamento e processa- 
mento da informação 


Num sistema baseado na utilização 
de terminais e orientado para o con- 
versacional, o processo de acesso por 
excelência é o acesso directo ou aleató- 
ro. 

Sendo a velocidade de resposta, um 
factor importante, tais processos de- 
vem ser utilizados sempre que possí- 
vel. Contudo, apesar da existência da 
Base, um ficheiro organizado aleato- 
riamente pode frequentemente ter que 
ser utilizado num processamento serial 
em lote. Neste caso, tal ficheiro terá 
“um rendimento inferior ao que teria se 
estivesse sequencialmente organiza- 
do. O que o utilizador ganha num caso, 
perde-o muitas vezes no outro. Ora, tal 
situação não pode ser tolerada. Ao lon- 
go do tempo, têm sido utilizadas inde- 
xações com solução de compromisso 
para a resolução de tal problema. Infe- 
lizmente, tais compromissos só têm 
servido para que o utilizador se con- 
vença que não é possível obter o máxi- 
mo rendimento em ambos os casos. 

Idealmente portanto, deverão estar 
disponíveis num DBMS as técnicas ne- | 
cessárias para que seja possível cor- 
responder com elevada capacidade de | 
resposta às necessidades dum sistema |. 
baseado em terminais e portanto utili- 
zando o acesso directo, mas também | 
para permitir o processamento em lo- | 
tes, a velocidades idênticas ou superio- 
res ao processamento sequencial, sem | 
ordenar o ficheiro. 

O projectista do sistema não deverá 
também ficar sobrecarregado com a 
determinação de algoritmos de acesso | 
aleatório, manuseamento de sinóni- 
mos, ou com a gestão do espaço em | 
disco. As reestruturações periódicas 
deverão, ainda, ser absolutamente evi- 
tadas, ou seja os ficheiros deverão ser | 
optimizados por si próprios após contí-. | 
nuas inserções e anulações de regis- | 
tos. 


3. O sistema deve permitir a indepen- 
dência da informação ao nivel de ele- 
mento de campo. 


O armazenamento de informação e a 
sua apresentação devem ser indepen- 
dentes ou transparentes até ao nível de 
elemento (campo). Só com tais caracte- 
rísticas é possível ao utilizador corres- 
ponder às alterações provocadas pela 
dinâmica do condicionalismo dos negó- 
cios. Uma aproximação que permita 
um progresso continuo e uma evolução 


INFO. 


constante, é essencial. A medida que 
forem necessários nqvos elementos de 
informação, deve ser possível promo- 
ver a sua inserção, quer nos registos já 
existentes, quer na estrutura da infor- 
mação, sem provocar um impacto ne- 
gativo no sistema operacional e nos 
programas de exploração. Tal facto 
- não deve ainda implicar a recompila- 
ção de programas existentes, nem o 
redesenho do sistema em sí. 

Como atrás se indicou, nas aproxi- 
mações tradiciona's nos casos em que 
um ficheiro serve « base a ur siste- 
ma de gestão de informação não inte- 
grado, o problema levantado pela defi- 
ciência apontada no momento da mani- 
pulação da informação, é aparente, 
mas logo que a modificação ocorrida 


num ficheiro se ramifique ao longo de 


todos os sistemas da companhia, a de- 
ficiência já não pode ser tolerada. 

Sem a independência da informação 
ao nível de elemento, o projectista do 
sistema não tem outra alternativa se- 
não prever à partida todos os condicio- 
nalismos capazes de efectuar cada ele- 
mento de informação ou o próprio sis- 
tema. Tal antecipação da realidade po- 
de dar origem a um trabalho de meses 
ou anos, que acabará por se verificar 
ser, de qualquer forma, marginalmen- 
te correcto. Quaisquer adiamentos e 
demoras verificados no progresso e e- 
volução dos sistemas, provocam ericar- 
gos, não somente os referentes aos 
custos dilatados de implementação, 
mas também nos que se traduzem no 
facto de não serem percebidos os be- 
nefícios resultantes da sua imediata 
aplicação. 

Um sistema que permita não gastar 
50 000800 num ano, se fôr aplicado so- 
mente um ano depois, provoca um cus- 
to real de 50 000800. 


4. O sistema tem de eliminar a re- 
dundância 


Para além de existir um controlo n- 
goroso sobre a informação, não é pos- 
sível tolerar qualquer duplicação ou re- 
dundância. Os problemas levantados 
pela aplicação prática de tais imperati- 
vos são já bem conhecidos, pelas ten- 
tativas realizadas para os atingir. Se o 
DBMS for realmente independente ou 
transparente ao nível de elemento e, 
se além disto permitir a utilização de 
processos flexíveis de estruturação da 
informação, não haverá razão alguma 
para que o projectista do sistema o 
conceba com informação redundante. 

Contudo, as limitações ou condi- 
cionalismos impostos por certas técn:- 
cas de associação ou relacionação, for- 
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çam muitas vezes os projectistas a pro- 
ceder a duplicações intencionais. As 
soluções encontradas para os proble- 
mas de redundância e da associação 
podem ser melhor apercebidas, atra- 
vés duma breve discussão acerca de 
tais objectivos. 

Entre os ficheiros tradicionalmente 
existentes numa empresa industrial, o 
sistema de encomendas deve prever 
um ficheiro de encomendas contendo 
um registo por cada encomenda. Cada 
registo é identificado pelo número de 
encomenda e conterá informação tal 
como o nome do cliente e a quantida- 
de, código e descrição de cada artigo 
encomendado. 

O sistema de clientes por sua vez 
deve prever um ficheiro de Clientes 
em que cada reçisto será eventual- 
mente ** io pelo número de 
cliente e inciuirá informação referente 
ao seu nome e ao valor em débito. Para 
além destes ficheiros, existirá ainda 
um de Inventário, no qual cada registo 
será possivelmente identificado pelo 
número de artigo, e conterá toda a in- 
formação pertinente. Obviamente, 
uma grande quantidade de informação 
aparecerá duplicada em dois ou mais 
dos ficheiros existentes. 


No sentido de resolver tal problema, 
vamos supor que a empresa em ques- 
tão decide promover a implementação 
duma Base de Dados. Cada elemento 
de informação só deverá ser armazena- 
do uma vez. Contudo, uma vez que to- 
dos os departamentos da companhia 
irão utilizar a Base de Dados, a infor- 
mação deverá estar organizada de tal 
forma que permita o acesso, a cada de- 
partamento, à informação que lhe é 
pertinente. 

Um dos problemas que imediata- 
mente se levanta é o de eleger a chave 
da Base de Dados. Se for escolhido o 
número de encomenda como único 
ponto de entrada, o departamento de 
clientes ver-se-á em sérias dificulda- 
des para conhecer qual o valor total em 
débito de um cliente. Se for escolhido o 
número de cliente, os empregados de 
armazém não conseguirão determinar 
qual a existência de determinado arti- 
go. Em consequência, a concepção da 
Base de Dados deve permitir a existên- 
cia de vários pontos de entrada, cor- 
respondendo às necessidades das vá- 
rias apiicações. A informação deve ser 
orponizada por forma a que cada de- 
peramento possa aceder eficiente- 
"1 à informação que lhe é referen- 
t>, cmbora evitando a existência de re- 
dundância. Os métodos de representa- 
ção lógica das inter-relações existen- 
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Fig. 1.1 — Estrutura arborescente. Hierar- 
quia num só sentido 


tes, a nível da organização em ficheiro 
serão examinadas de seguida. 

a) Algumas Bases de Dados em 
uso, empregam um processo de repre- 
sentação arborescente para represen- 
tar as relações lógicas existentes entre 
a informação. ''Uma estrutura hierár- 
quica na qual cada elemento pode ser 
relacionado com ''n'' elementos de ní- 
vel inferior, mas com um único ele- 
mento de nível superior. Contudo, o e- 
lemento de mais alto nível tem somen- 
te dependentes e é conhecido por 
raiz” (1). º 


A figura 1.1 representa uma estrutu- 
ra arborescente. 


1 41) CODASYL DATA BASE TASK GROUP 
OCTOBER 69 REPORT. 

O elemento “A” é a raiz. Cada 
elemento tem zero ou mais ramifica- 
ções para o nível inferior. Por exem- 
plo, há três ramificações a partir do 
elemento “B” e a terminar nos 
elementos “D”, “E” e ““F"*. Contudo, 
em cada elemento (excepto “A”, que 
é a raiz) termina um e só um ramo. 

A representação arborescente é 
adequada para algumas estruturas de 
informação. Por exemplo, consideram- 
*se os alunos de determinada Universi- 
dade, matriculados cada um em várias 
disciplinas. Cada aluno pode ser consi- 
derado a raiz da estrutura. Cada disci- 
plina em que está matriculado pode 
ser considerada um elemento depen- 
dente da raiz, tal como representado 
na Figura 1.2. 

Um conjunto de representações 
formará uma Base de Dados em que o 
ponto de entrada será o aluno, ou seja 
a raiz duma arborescência. 


Elenentos | Cálculo 
Tienentar 


as A 
de "isica 


Fig. 1.2 — Representação Arborescente do 
curso dum aluno 
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Poderá. eventualmente ser neces- 
sário saber quais os alunos matricu- 
lados em determinada disciplina. 
Neste caso, a disciplina seria a raiz e 
os alunos os elementos dependentes. 
Tal estrutura é a da Fig. 1.3. - 


Cálculo 
Elementar 


| FRANCISCO | 


Fig. 13 — Representação Arborescente das 
Matrículas numa disciplina 


Um conjunto de representações 
idênticas formaria uma Base de Dados 
e a raiz, a disciplina, seria o seu ponto 
de entrada. 

b) Suponha-se agora que se pre- 
tendia efectivamente implementar a 
Base de Dados para tal Universidade. 
Os vários professores desejariam utili- 
zá-la a partir da raiz “disciplina”; para 
conhecerem quais os alunos matricu- 
lados nas disciplinas que leccionavam. 
O pessoal relacionado com os alunos 
pretenderia utilizar a raiz “estudante”” 
para terem acesso a toda a informação 
que lhe era referente. Se um e um só 
destes exemplos fosse considerado, 
um dos grupos de utilizadores não te- 
ria acessô eficiente à informação pre- 
tendida. Se ambas as Bases de Dados 
fossem implementadas, uma grande 
porção de informação ficaria duplica- 
da. Se é de facto necessário resolver o 
problema da redundância, é essencial 
uma estruturação da Base de Dados 
diferente, por exemplo a indicada na 
Fig. 1.4. Tal técnica de estruturação ou 
associação é conhecida por “Base de 
Dados de estrutura em rede”. 


CALCULO 
ELEMENTAR 


N Ón 


SECÇÃO A 


APROVEITAMENTO 94% 


Fig. 1.4 — Estrutura de comunicação em 
qualquer direcção duma Base de Dados 


A Base de Dados pode ser acedida 
quer através das disciplinas ou do es- 
tudante e não se verifica duplicação. 
Como nos exemplos anteriores, os 
elementos dependentes representam 
informação, que existe, porque um 
determinado estudante se encontra 
matriculado em certa disciplina. 
A secção do curso referente a cada alu- 
no e o seu aproveitamento constituem 
tal informação. Contudo, uma vez que 
os elementos dependentes são acedi- 
dos por mais do que uma ramificação, 
a estrutura indicada não é do tipo arbo- 


SECÇÃO B 
APROVEITAMENTO 89% 


rescente. A informação desejada não 
pode ser eficientemente representada 
por tal tipo de estrutura. 

O problema atrás encontrado é 
frequentemente comum. Surge, por- 
que as inter-relações naturais existen- 
tes na informação da maior parte das 
organizações, são demasiado comple- 
xas para que possam ser representa- 
das - somente por uma estrutura 
arborescente. É necessário outro tipo, 
para permitir uma Base de Dados 
eficiente e flexível. 

O entrelaçamento é a mais flexível 
e poderosa das estruturas da informa- 
ção. Nesta “rede””, qualquer elemento 
pode ser relacionado com qualquer nú- 


“mero de outros, quaisquer que eles 


sejam. Em particular, tal implica que a 
qualquer elemento possa estar asso- 
ciado qualquer número de ramos ou 
de indicadores, os quais podem 
“entrar” ou sair dele. Desta forma, os 
problemas resultantes da necessidade 
de pontos de entrada variados, de es- 
truturas poderosas e flexíveis, da asso- 
ciação de informação e da inexistência 
de informação e da inexistência de re- 
dundância, ficam (resolvidos. 


5. A integridade e a segurança 
da informação são essenciais 


“Integridade e segurança, são mui- 
tas vezes utilizadas como sinónimos. 
Apesar de ambos os requisitos essen- 
ciais, a importância da integridade 
(protecção) é primordial. Todas as 
salvaguardas, contra o mau funciona- 
mento “hardware””, dados deficientes, 
erros de programação e operação, 
devem ser previstas. O DBMS tem de 
proteger a Base de Dados, e no caso 
não desejável de erro, deve prever 
técnicas de reinício de trabalho e de 
recuperação, rápidas e eficientes. 
Tais técnicas devem poder funcionar 
em todos os condicionalismos: multi- 
programação, multiprocessamento, 
etc., e devem ser compreensivas. 
O requisito crítico da integridade da 
informação não deve ser unicamente 
realçado. É um imperativo. 

A segurança da informação 
(privacidade) deve ser tal que os dados 
devem estar seguros não só do nível da 
própria Base, mas também a nível de 
ficheiro ou até ainda de elemento. 
Uma vez que os padrões de segurança 
se alteram ao longo do tempo, devem 
estar previstas técnicas fáceis de im- 
plementação e modificação. 

Mais ainda, uma vez que os graus 
de segurança pretendidos podem ser 
variáveis, é desejável que o próprio 


utilizador possa conceber o seu 
programa de segurança. 


6. O sistema deve ser independente 
em relação ao condicionalismo 
ambiente 


Uma vez que o utilizador evoluirá 
ao longo do tempo, e conhecerá por- 
tanto condicionalismos de operação di- 
versos: processamento de lotes, inter- 
rogações em  teleprocessamento, 
actualizações em teleprocessamento, 
ou pode até trabalhar concomitante- 
mente em alguns deles, o DBMS deve 
ser independente ou transparente a 
tais condicionalismos. 

As conversações necessárias para 
permitir a utilização de novo 
“hardware” ou “'software””, devem 
também ser eliminadas. 

Por exemplo, o DBMS e qualquer 
aplicação devem funcionar em proces- 
samento em tempo real, e não podem 
inibir a utilização de quaisquer técni- 
cas particulares de controlo dum 
terminal especializado. 

Esta área é, em particular, uma 
das que tem sido e terá de continuar a 
ser dinâmica. Sem liberdade para po- 
der ser sensível às rupturas onde quer 
que elas ocorram, os utilizadores que 
implementem Bases de Dados e per- 
maneçam de braços cruzados, encon- 
trar-se-lão dum dia para o outro 
rodeados de técnicas obsoletas, e 
serão obrigados a novo e traumático 
esforço de conversão. 

A única salvaguarda possível para 
tal problema é a obtenção da certeza 
que o DBMS que se implementa é 
completamente independente em rela- 
ção ao condicionalismo de operação e 
ao próprio equipamento. 


7. O sistema deve ser independente 
em relação ao equipamento e à 


linguagem 


A selecção de linguagens (CO- 
BOL, PL/1, etc.) é efectuada para 
permitir uma melhor satisfação das 
necessidades correntes do utilizador. 
Podem inclusive existir casos de em- 
presas que empreguem, conforme as 
aplicações, FORTRAN e COBOL, por 
exemplo. Por outro lado os utilizadores 
evoluem duma linguagem para outra: 
AUTOCODER para COBOL e depois 
para PL/1. Uma vez que tal condicio- 
nalismo ainda se continuará a verificar 
no futuro próximo, é imprescindível 
que o DBMS seja independente da 
linguagem. 

Deverá ser possível aos técnicos, 
utilizar FORTRAN sobre uma Base de 
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Fig. 2 — Grafo que representa esquematicamente o conteúdo da Base de Dados 


Neste grafo, uma ligação 

25 caracteres alfabéticos e nome * 
UNIVERSIDADE 

quer dizer que na base de dados há um 
conjunto de universidades, que cada 
universidade possui um nome que é 
uma sequência de 25 caracteres alfa- 
. numéricos; uma ligação 
UNIVERSIDADE e constituinte! — 
* FACULDADE 


quer dizer que na base de-dados há um 
conjunto de universidades e um con- 
junto de faculdades e que entre as uni- 
versidades e as faculdades há uma re- 
lação a que se chama de “'constituin- 
tes-1”". 

Se pretendessemos definir a parte 
do “schema” que corresponde, numa 
1.º fase teríamos o seguinte: 
schema currículos 
record Universidade 

02 nome pic A (25) 

02 código pic 9 (2) 
record Faculdade 

02 tipo pic A (25) 

02 código pic 9 (2) 
record Curso 

02 tipo pic A (25) 

2 código-Ipic 9 (4) 


record Disciplina 
02 tipo-ipic A (50) 
02 código-lIpic 9 (4) 
02 anopic 9(1) 
set constituintes-1 
owner Universidade 
member Faculdade 
set constituintes-2 
owner Faculdade 
member Curso 
set constituintes-3 
owner Curso 
. member Disciplina 
Numa 2.º fase de definição, o DBA 
tem que fornecer indicações destina- 
das a influenciar a estruturação dos 
dados. 

Se, por exemplo, o acesso a todas 
as disciplinas dum determinado tipo 
for muito frequente ou se se pretender 
economizar memória, o DBA pode 
transformar o “Schema”, optando pe- 
la nova versão seguinte: 
record Universidade 

02 nome pic A (25) 

02 código pic 9 (2) 
record Faculdade 

02 tipo pic A (25) 

02 código pic 9 (2) 
record Curso 

O2tipo pic A (25) 

02 código-lpic 9 (4) 


record Disciplina 
02 código-lpic 9 (4) 
02 ano-ciúrricular pic 9(1) 
record auxiliar 
02 tipo-lpic X (50) 
set suplementar 
owner auxiliar 
member disciplina 
set constituintes-1 
owner Universidade 
member Faculdade 
set constituintes-2 
owner Faculdade 
member Curso 
set constituintes-3 
owner Curso 
member Disciplina 
Com esta nova versão, o SGBD 
criará listas que permitirão o acesso 
rápido (por percurso do set “auxiliar'”) 
a todas as disciplinas dum determi- 
nado tipo. 


o ida sq a 
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1. INTRODUÇÃO 


Os sistemas gerais de Bases de Da- 
dos com estrutura em rede podem ser 
exemplificados pelos sistemas que o- 
bedecem às especificações do ''Data 
Base Task Group (DBTG) do comité 
“Codasyl"" (1) publicadas em Abril de 
1971. 

A principál diferença entre um mo- 
delo com estrutura em rede e um mo- 
delo com estrutura hierárquica reside 
no número de antecessores (pais) ad- 
mitidos por um nó (Fig. IA e B): en- 
quanto que no modelo hierárquico um 
nó pode ter no máximo um antecessor. 
no modelo em rede ele pode ter vários 


2) (6) (4 
) (6) 6) O (9) 


Fig. IA —Modelo com estrutura hierárquiça — 
O nó | (Illé o antecessor dos nós 2, 3 e 4: por sua 
vez o nó 2 é antecessor dos nós 5 e 6. 


3) (4 
(6) (0) 


5) 
8) (9) 


Fig. IB — Modelo com estrutura em rede — o 
nó 4 tem dois acessores: onó le o nó 2. 


SGBD EM REDE 


A possibilidade de existência de vá- 
rios antecessores facilita o problema 
da representação de relações de certo 
tipo do mundo real (por exemplo a re- 
lação existente entre fornecedores e 
produtos fornecidos: um fornecedor 
pode fornecer vários produtos e um 
produto pode ser fornecido por vários 
fornecedores). 

Existem várias implementações de 
Sistemas Gerais de Bases de Dados 
(SGBD) que obedecem às especifica- 
ções de linguagem propostas pelo D.B. 
T.G. “CODASYL”. Neste artigo refe- 
rir-nos-emos — essencialmente aos 
SGBD 'DBMS'"” da DEC e “'DMS/ 

1100" da Univac. 

No DBMS da DEC e no DMS da 
UNIVAC, do mesmo modo que nos 
SGBD hierárquicos ou outros SGBDs 
em rede, existem três tipos de lingua- 
gem destinadas em princípio a três ti- 
pos de utilizadores: 


— Em 1.º lugar temos a linguagem 
de definição ''DATA DEFINITION 
LANGUAGE" (DDL) destinada ao ad- 
ministrador ( ou grupo de administra- 
dores) da Base de Dados — “'DATA 
BASE ADMINISTRATOR" (DBA). 


— Epa 2.º lugar temos, para a mani- 
pulação dos dados, a “DATA MANI- 
PULATION LANGUAGE" (DML). Es- 
ta linguagem é utilizada, normalmen- 
te. pelos programadores de aplicação. 


— Em 3.º lugar existe ou podemos 
definir uma linguagem de utilização 
destinada a utilizadores não informáti- 
cos, 


Ana Sales 
Universidade Nova de Lisboa 


2. DEFINIÇÕES 


Vejamos a seguir alguns, conceitos 
próprios dos SGBD de tipo CODASYL: 
“Schema”: Descrição completa da 
Base de Dados. 

“Sub-Schema": Subcbnjunto do 
esquema. Permite controlar a 
confidencialidade dos dados e- 
xistentes na Base de Dados. 

“Área”: Parte da Base de Dados 
externamente atribuída a um 
“device”, 

“Page”: Sub-divisão da área; é a 
unidade de ““input/output” ou 
seja o bloco lógico. 

“Record"": Unidade lógica de tra- 
tamento; constituída por 
“items”. 

“Set”: Representa uma relação 
entre “'records"" de tipos dife- 
rentes; num “set” temos sem- 
pre um tipo de “'record"' decla- 
rado como sendo o ''owner'” do 
“set” e um ou vários outros ti- 
pos de ''records"" declarados co- 
mo sendo ''members"' do “'set” 

Vejamos com mais pormenor, as 

diferentes linguagens. 


3. LINGUAGEM DE DEFINIÇÃO 
DOS DADOS 


As três principais funções desta 
linguagem são: 

— Definir esquematicamente o con- 
teúdo da Base de Dados. 

—bDar indicações gerais para a es- 
truturação dos dados. 

— Estabelecer critérios de controlo 
de concorrência, confidencialida- 
dee integridadedos dados. 
Consideremos, a título de exem- 

plo. uma Base de Dados do Ensino Su- 
perior contendo, entre outras, infor- 
mações sobre currículos esquemati- 
camente representadas pelo grafo da 
figura 2. 
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Dados, na qual os ficheiros possam 
igualmente ser manipulados por pro- 
gramas escritos em COBOL ou PL/1. 
Os utilizadores que actualmente utili- 
zam COBOL ou PL/1 devem poder 
evoluir à medida que novas e mais efi- 
cientes linguagens forem aparecendo. 

- Tal independência deverá ainda 
verificar-se no que se refere ao tipo de 
equipamento e respectiva marca. 

Por exemplo, as companhias que 
utilizarem equipamentos de diferentes 
marcas ou distintos sistemas de opera- 
ção devem poder utilizar uma Base de 
Dados idêntica. O utilizador que tra- 
balhe em DOS e o que utiliza OS 
devem ser compatíveis e deve existir 
plena possibilidade de transferência 
de programas e da Base de Dados. As 
conveniências actuais são impor- 
tantes, mas a liberdade de escolha do 
futuro é vital. A independência em re- 
lação ao tipo e marca do equipamento 
é essencial para que seja possível ao 
utilizador tirar vantagem duma nova 
tecnologia apresentada pela mesma 
marca utilizada, ou para que seja pos- 
sível no futuro comprar novos equipa- 
mentos e decidir pelo mais adequado, 
sem ter de sofrer um grande esforço 
de conversão. 

Sem independência do DBMS, o 
utilizador fica “'enclausurado” na 
tecnologia actual, ainda que tenha 
escolhido o COBOL para evitar tal 
malefício. 


8. Rendimento óptimo e eficiência 
em todos os casos 


Nos sistemas convencionais é mui- 
tas vezes concedida grande atenção à 
minimização dos tempos de processa- 


mento e dos espaços ocupados pelos . 


ficheiros. Na realidade tais preocupa- 
ções são legítimas, ainda que só em 
relação a algumas aplicações ou pro- 
gramas o problema se ponha com certa 
relevância. Com a utilização de uma 
Base de Dados, o problema passa a ser 
pertinente em relação a todas as apli- 
cações e a todos os programas, pelo 
que, velocidade e eficiência são 
características a explorar tanto quanto 
possível. Atingir tais objectivos não é 
na verdade fácil, já que eles se opõem 
mutuamente; o mínimo possível de 
espaço em disco e em memória, o má- 
ximo rendimento de saída. Para além 
de que, os factores devem ser evitados 
ao máximo, já que todos os programas 
serão afectados por tais inconve- 
nientes. ) 

Uma vez que estes requisitos se 
podem considerar como verdadeira- 
mente críticos, quaisquer compro- 
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missos não devem ser tolerados. 
O DBMS tem necessariamente de per- 
mitir a máxima eficiência, velocidade e 
rendimento em qualquer condiciona- 
lismo operativo. 

O nível de elaboração da gestão de 
espaço atingido pelo DBMS é extrema- 
mente importante. Frequentemente 
são encontradas versões em que as in- 
serções à Base de Dados são efectua- 
das em áreas de “overflow”. 

— Uma vez que tal prática tem bas- 
tantes efeitos negativos, os desenha- 
dores de sistemas prevêm normalmen- 


. te espaço para um conjunto de infor- 


ção bastante superior ao existente no 
momento. Todavia, o espaço extra que 
assim é ocupado pode ser bastante si- 
gnificativo. Como já se afirmou atrás, 
os compromissos que provocam bene- 
fícios em determinada área podem 
mostrar-se bastante inconvenientes 
noutras. Idealmente, as técnicas de 
gestão de espaço devem estar contidas 
no próprio DBMS e devem prever a re- 
solução dos problemas indicados, se 
possível, com a menor interferência 
possível do utilizador. 


9. O SISTEMA DEVE PERMITIR 
UMA CERTA FACILIDADE NA FASE 
DE TRANSIÇÃO 


A conversão necessária dum siste- 
ma de informação não integrado para 
um sistema integrado utilizando uma 
Base de Dados, terá ao longo de um 
peíodo de tempo bastante extenso. O 
investimento já efectuado pelos utili- 
zadores nos sistemas existentes deve- 
rá ser tanto quanto possível aprovei- 
tado. Tal como as vantagens de uti- 
lização duma Base de Dados são óbvi- 
as, também são perfeitamente conhe- 
cidos os problemas levantados pela fa- 
se de conversão. No sentido de resol- 
ver o problema da redundância nos fi- 
cheiros existentes, à medida que tal in- 
formação for transferida para os novos 
ficheiros da Base de Dados, deverá o 
DBMS prever uma técnica que permita 
ao utilizador efectuar tal transferência 
com o mínimo de esforço e aproveitan- 
do tanto quanto possível o investimen- 
to já efectuado. 

O DBMS deveria, idealmente, im- 
plicar somente ligeiras modificações 
nos programas do utilizador, mormen- 
te nas áreas de acesso (READS e WRI- 
TES), e permitir-lhe portanto desde lo- 
go a utilização dos novos ficheiros da 
Base. Desta forma o utilizador poderia 
retirar as seguintes e bem desejáveis 
vantagens: 
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i—Protegeria o investimento efectua- 
do nos programas já existentes. Na 
realidade poderá até tirar deles um 
proveito bem maior, já que irão uti- 
lizar os novos ficheiros e a Base, do 
que resultam vantagens imediatas. 


2—0 utilizador pode dispensar mais 
atenção ao desenho e à implemen- 
tação de novos sistemas, o que lhe 
permitirá obter mais cedo, maiores 
benefícios. | 


3—0 redesenhar dos sistemas mais 
antigos poderá ser efectuado com 
tempo e com cuidado, e não em si- 
tuações de desespero ou de tempo 
contado, do que resultará certa- 
mente uma concepção mais perfei- 
ta. 


4—Seria possível eliminar o processa- 
mento, normalmente prolongado, 
de aplicações em paralelo, evitando 
a sobrecarga de conseguir um pro- 
grama de interligação entre o siste- 
ma antigo e o sistema novo. 


S— Permitir-lhe-ia a imediata elimina- 
ção da informação redundante. 


REVISTA “INFORMÁTICA” 
PUBLICOU 


“NORMAS PARA A INSTALAÇÃO DE 


UM CENTRO DE INFORMÁTICA” 


no 
Vol. 1 N.º 2,3,5 
Vol.2 N.º1,3,4 
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Note-se que, embora o DBA dê in- 
dicações para a estruturação dos da- 
dos, ele não tem de se preocupar com 
problemas do tipo: 

—Qual o tipo ou tipos de suportes 
“dos ficheiros? 

—Qual a ordem de implementação 
física dos records? 

Estes problemas não fazem parte 
da definição de Base de Dados e por is- 
so muitas vezes se diz que os SGBD 
são “'DATA-INDEPENDENT"' (3). 

Os parâmetros a fornecer pelo 
DBA são: ' 

“Número e nome das “'Áreas” 
pretendidas 

—Qual a dimensão das “'Pages” 
(4) 

—Qual o tipo de acesso a privile- 
giar para os diferentes tipos de “'re- 
cords”: 

e por chave externa 

e através dum ''set”” 

º fornecendo uma chave 

interna 

—Qual o tipo de ''set'' que se pre- 
tende: 

* “'set” implementado 
por uma lista circular 
(lista constituída pelo 
“owner” e seus ''mem- 
bers”. 

“Mode chain”. (fig.3) 


e “'Set'” implementado 
por uma lista de aponta- 
dores. A cabeça da lista 
ligada é o “owner” do 
“set”” e os ''apontado- 
res” da lista são aponta- 
dores para os ''mem- 
bers"" da ocorrência (5) 
do “'set"': 

“Pointer array” (só exis- 
te no “DMS”) (Fig.3). 


— Se se pretende ou não mais liga- 
ções entre ''*members”' do “set” ou 
seja se se pretende que todos os 
“members” de um “'set”' se encon- 
trem ligados ao ''member”” anterior 
(“linked prior”) e/ou que todos os 
“members” se encontrem ligados ao 
“owner” (“linked owner”). (Fig.3). 

—Qual o tipo de ordenação pre- 
tendida para os “members” de um 
“set” e qual a chave de ordenação. 

—Se se permite a existência de 
“members” com a mesma chave de 
ordenação. 

—Se se pretende que sempre que 
se arquive um “'record”” na Base de 
Dados ele fique ligado a todos ou al- 
guns dos “'set”” de que é '“'member” 
(member automatic””). 


Voltando ao '“'schema”” definido a- 
trás e considerando só uma parte dele, 
a introdução destes vários parâmetros 
poderia resultar no seguinte: 


Records-per page 20 
assign area - 8 to MON 
first page is 1 
last page is 50 
page size is 284 words. 


schema currículos. 
area area - À 
record Universidade 
location cale using nome duplicates not 
allowed 
within area - B. 
02 nome pic x (25). 
02 código pic 9 (2). 
record Faculdade 
location via constituintes 
-1 set 
within area - HF. 
02 tipo pic A (25). 
02 código pic 9 (2). 
set constituintes - 1 
mode chain 
order alway next 
owner Universidade 
member Faculdade 
automatic 


Mas é porque uma Base de Dados 
serve em princípio 
a DDL permite também o controlo da 
confidencialidade, concorrência e inte- 
gridade dos Dados. 


4. CONFIDENCIALIDADE 


O controlo da confidencialidade é 
feito definindo “'sub-schemas”. 

Como já se viu um ““sub-schema”” 
define o sub-conjunto da base de da- 
dos que se admite que um determina- 
do utilizador possa aceder. O DBA terá 
portanto que especificar: 

—Quais as “áreas” às quais per- 
mite o acesso. 

—Quais os “records” dessas “'a- 
reas” a que o utilizador tem direito de 
aceder; dentro do “'record”. O DBA 
também pode limitar os “items” a 
aceder pelo utilizador. 

—Quais os “'set”” acessíveis. 

Naturalmente, pode acontecer que 
o DBA permita a um utilizador o aces- 
so a toda a Base de Dados. 

A cada “'sub-schema” é atribuída 
uma chave que é fornecida ao utiliza- 
dor do “'sub-schema”. Contudo, mui- 
tas vezes pretende-se que determina- 
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da classe de utilizadores de um ““sub- 
-schema”” só consulte a Base de Dados 
e que outro conjunto a consulte e a- 
ctualize. Como o ''sub-schema”” só a- 
dmite um “lock””, o DBA resolve este 
problema indirectamente, aferrolhan- 
do as “areas” com ““locks”” de leitura 
e “locks”” de actualização e fornecendo 
às diferentes classes de actualizado- 
res, além da “Key” do “'sub-schema” 
as “key” das “Areas”. 

Por exemplo, se se pretendesse 
somente um “sub-schema”” que per- 
mitisse o acesso a toda a Base de Da- 
dos, o DBA juntaria à definição do 
“schema” qualquer coisa do tipo 


sub-schema subl privacy chave. 
area section. 
copy all areas. 
record section. 
copy all records. 


set section 
copy all sets 


5. CONCORRÊNCIA 


À concorrência surge devido a: 

— Existirem vários utilizadores 

—Existir a possibilidade de actua- 
lizações constantes. 

Os SGBD de que estamos a tratar, 
permitem normalmente 7 regimes de 
concorrência: 


— Carregamento (para o carrega- 
mento inicial da Base de Dados) 

— *““retrieval”” (consulta) 

— “Update” (actualização) 

— **Protected retrieval”” (consulta 
por um utilizador; permite so- 

— mente a existência de outros 
utilizadores no regime “Re- 
trieval””) 

— **Protected update” (actualiza- 
ção por um utilizador; permite o 
“Retrieval”” a outros utiliza- 
dores) 

— “exclusive retrieval”” (Monopó- 
lio do acesso à base de dados 
por um utilizador que só faz 
consulta) 

— ““Exclusive update”” (monopó- 
lio do acesso à base de dados 
por um utilizador que só faz 
consulta e actualizações). 


A nível do '“schema””, o DBA colo- 
ca nas várias áreas os “lock” adequa- 
dos aos regimes pretendidos. 

6. INTEGRIDADE 


Para evitar a destruição, por “sys- 
tem-crash””, por erros de programação 
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ou mesmo por erros do próprio SGBD, 
de dados existentes na Base de Dados 
o DBA pode pedir ao SGBD na altura 
da definição do “'schema”, a criação 
de cópias. As cópias podem ser ante- 
riores e/ou posteriores a cada actuali- 
zação ou conjunto de actualizações. 

Para recuperar a Base de Dados, 
existem depois programas utilitários 
que fazem, a pedido do utilizador ou 
DBA, a integração total ou parcial das 
cópias na Base de dados. 

Note-se que, se o DBA não tiver 
pedido cópias quando definiu o “*sche- 
ma”, os programadores de aplicação, 
utilizando utilitários, podem fazê-lo. 


7. MANIPULAÇÃO DOS DADOS 


Os programas de carregamento, 
consulta e actualização são escritos uti- 
lizando a DML (DATA MANIPULA- 
TION LANGUAGE). A DML é uma 
sub-linguagem de linguagens de alto 
nível (cobol e/ou fortran e/ou PL/1) ou 
de ''Assembler” 


Toda a manipulação de dados se 


baseia na: 


—transferência de “'records” um 
a um; não se pode pedir de uma só vez 
a transferência de todas as Universida- 
des. 


— existência de “'currents”” para' 


todos os tipos de “'record” e “'set”” e 
ttarea”. 

O “current”” de um tipo de “'re- 
cord” é a última ocorrência desse tipo 
de “record” a ser acedida pelo progra- 
ma de manipulação. O “'current” de 
um tipo de “set” é a última ocorrência 
desse tipo de “'set'” a ter sido acedida: 
uma ocorrência de um tipo de “set” 
torna-se o “current”” desse tipo de 
“set” ou porque o seu “owner” ou 
porque um dos seus “members” se 
tornou corrente. 


Os programas escrevem-se facil- 


mente, pois todo o controle de fichei- 
ros, registos, etc., é deixado ao SGBD 
embora a eficácia da sua execução de- 
penda da estrutura dos dados escolhi- 
da no ““schema””. 

Assim, se se pretendesse listar to- 
dos os códigos e nomes das Faculda- 
des da Universidade de código 04, ha- 
veria pelo menos duas possibilidades: 

—4A 12 seria percorrer todas as Fa- 
culdades existentes na Base de Dados 
e para cada faculdade ver se o “ow- 
ner”” tinha código 04. 

—A 22 possibilidade seria percor- 
rer todas as Universidades até encon- 
trar a universidade de código 04. Se- 
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guidamente percorrer-se-ia simples- 
mente a ocorrência do “set” ““consti- 
tuintes-1”” com o '*owner”” encontra- 
do. 

Esta solução é mais rápida e efi- 
ciente do que a primeira pois tem em 
consideração o facto das faculdades de 
uma Universidade estarem ligadas pe- 
lo “set” ““constituintes-1””. 

Vou apresentar a programação a- 
dmitindo a segunda hipótese. 


Find first Universidade record of area- 
-O area. 
If not cond (status) (6) 
Get 
Perform P1 until código 
of Universidade = 04 
and cond (status). 


If código of Universidade 


Find first Faculdade of 
constituintes-1 Set Per- 
form p2 until cond (sta- 
tus). 


pl. 


Find next Universidade 
record of area-0 area. 
Ifnot cond (status) 

Get. 


p2. 


Get 

(tratamento) 

Find next Faculdade of 
constituintes-1 set. 


Vejamos agora como é que se es- 
crevem programas de aplicação. 


Os programas de aplicação come- 
çam sempre por invocar o “sub-sche- 
ma” com que vão trabalhar. 

“invoke sub-schema sub-1 
privacy key compile chave””. 

Esta cláusula permite que toda a 
parte da Base de Dados definida seja 
“sub-schema”” seja posta à disposição 
do utilizador. 

Quando um “'sub-schema” é invo- 
cado, é criada uma “User Working 
Area” (UWA). Nesta área de trabalho 
estão definidas zonas distintas para ca- 
da tipo de “record” e cada tipo de 
“item” do “sub-schema” invocado: o 
utilizador refere-se a estes ““data- 
-items” ou “records” pelo nome dado 
no “sub-schema”. Na UWA existem 
também um certo rúmero de zonas 
destinadas a conter informações de 
controlo. 
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8. EXEMPLOS DE PROGRAMAS 
ESCRITOS EM DDL 


Ex.º1 


“Listar todos os nomes de Univer- 
sidades”: 


Find first Universidade record of 
area-O area 
Ifnot cond (status) 
Get 
Perform p1 until cond (status). 


pl. (tratamento) 


Find next Universidade record of 
area-0 area 
Ifnot cond (status) 
Get. 


Ex.º2 


“Listar os códigos das Faculdades 
da Universidade do Porto e da Univer- 
sidade de Coimbra”: 

Como o ““record” Universidade 
pode ser acedido directamente forne- 
cendo o seu nome, o programa que 
responde à questão anterior pode ser: 


Move “Universidade do Porto” to 
nome. 


Ifnot cond (status) 
Find first Faculdade of constituin- 
tes-1 
set perform p1 until cond 
(status). 
Move ““Universidade de Coim- 
bra” to nome. 
Ifnot cond (status) 
Find first Faculdade of constituin- 
tes-1 
Set perform pl until 
cond (status). 


pi. 
Get. 
(Listagem) 
Find next Faculdade of constituintes-1 
set. 


Na primeira activação do parágra- 
fo pl o “'set”” constituintes-l corrente 
é o que tem por “owner” a Universi- 
dade do Porto; na 2.º activação do 
mesmo parágrafo o ''set”” constituin- 
tes-1 corrente é o que tem por 
“owner” a “Universidade de Coim- 


(Carregamento e actualização) 
“Suprimir todas as faculdades cu- 
jos códigos são superiores a 02”. 


Find first Faculdade of area-0 area 
Perform pl until cond (status). 


pl. 
Get 
IfCódigo 02 
Delete all 
only 


Find next Faculdade ofarea-0 area 


Se se empregasse “'Delete all” as 
Faculdades eram retiradas da base de 
dados obrigatoriamente. Se se empre- 
ga ''Delete only” só se retiram da 
Base de Dados as Faculdades de có- 
digo 02e que não tenham cursos. 

Repare-se ainda que quando se faz 
um “'Delete”" do ''owner'" se faz tam- 
bém o ''delete'” dos seus ''members” 
declrados como “automatic”. Os 
“members”” não “automatic” só são 
removidos (desaparece a ligação ao 
“set”). O “delete” de um “'record” 
propaga-se em cascata ou seja fazendo 
o “delete” das Faculdades, far-se“ia 
também o “*delete”” dos cursos, pois 
Curso é um ''member”” do ''Set”' cons- 
tituintes-2 de que Faculdades é um 
“owner”. No entanto os “records” 
Disciplina po: serem também '“'mem- 
bers”” dos “records” “auxiliar” não 
são suprimidos pelo “delete” do Cur- 
so. 


REVISTA “INFORMÁTICA” 
PUBLICOU 


“NORMAS PARA A INSTALAÇÃO 


DE INFORMÁTICA” DE UM CENTRO 


no 
Vol.1 n.ºs 2,3,5 
Vol.2 n.ºs 1,3,4 


9. LINGUAGEM DE UTILIZAÇÃO 


Esta linguagem, por destinar-se a 
utilizadores não informáticos, é uma 
linguagem não algorítmica. Quando 
não é fornecida pelo constructor, pode 
ser simulada utilizando programas in- 
teractivos de comandos. Assim, se se 
pretendesse listar todas as niversida- 
des o utilizador teria que dar por 
exemplo o comando “'LU””. 


NOTAS: 


(1) — O Comité ““Codasyl”" foi o 
grupo que estabeleceu regras para a 
standartização das linguagens da Base 
de Dados. 

(2) — Um nó pode ser pensado co- 
mo um registo da Base de dados. 

(3) — Pede-se ao leitor que reveja 
o conceito de '“Data-Independent”” no 
artigo sobre Modelos relacionados 
deste número. 

(4) — Contrariamente à DDL do 
DMS, a DDL do DBMS obriga a que 
qualquer ““area”” contenha o mesmo 
n.º de “records”. 

(5) — No “'schema” existe a defi- 
nição de tipos de “records” e de tipos 
de “'sets””; na Base de Dados existem 
ocorrências de tipos de “'set””: uma 
ocorrência de um “'set”” é determinada 
pela ocorrência do “owner” desse 
“set”. Um “set” pode ter um número 
ilimitado de ''members”. 

(6) — ““Cond (status)”” quer dizer 
“determinadas condições de erro”: 
qualquer instrução DML tem certas 
condições de erro. 


eee 
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TEKTRONIX 


- Terminais gráficos com software de suporte 


4» DataGeneral 


- Minicomputadores de aplicações gerais 
NOVA e ECLIPSE 


para qualquer computador 


- Sistemas médios de gestão 


- Sistemas gráficos de cálculo programáveis 
em BASIC 


- Sistemas de aquisição de dados 


- Terminais alfanuméricos : A E ; 
É s dota ã - Sistemas gráficos interactivos 


AMPE X 


- Unidades de discos até 200 MB 


- Terminais impressores 


9000000 


- Sistemas de desenho automático 


a rolos ou de mesa 


- Unidades de bandas 


- Funcionamento ON-LINE 
ou. OFF-LINE 


- Memorias em ferrite para PDP-11 


- Software básico de suporte 


- Controladores de unidades de disco € de ban- 
das para PDP-11 


- Extensa livraria de aplicações 


- Mesas digitalizadoras 


- Impressoras de linhas, 120 a 500 l.p.m 


- Impressoras de caracteres 120 a 160 c.p.s. 


Controladores para todos as tipos de minis 


Representantes em Portugal: 


À E quifoato de Laboratório, E 


Apartado 1100 Lisboa -1 Telef. 97 6551 


MODELOS RELACIONAIS 


0 — INTRODUÇÃO 


O modelo relacional que se apre- 
senta a seguir é da autoria de E. F. 
CODD e data de 1970 (1). 

Esquematizando, pode dizer-se 
que houve um antes e há um depois do 
Modelo Relacional. de CODD: 

— O antes é constituído pela aplica- 
ção da noção de relação binária no tra- 
tamento de dados (2) (3). 

— O depois é constituído pela apli- 
cação de relações com n argumentos 
(n 1) e das operações correspon- 
dentes no tratamento de dados. 

Na conclusão veremos que o Mo- 
delo Relacional de CODD enferma de 
deficiências (outros modelos têm sido 
aplicados com maior êxito) o que não 
impede qne continue a ser a referência 
principal para a concepção de Sistema 
de Gestão de Bases de Dados (SGBD). 
A principal deficiência é não integrar 
mecanismos para verificações automá- 
ticas de coerência nem para dedução 
de dados (secção 5). 


1 — MODELO RELACIONAL 
DE CODD 


Codd constatou que em Gestão, ao 
contrário de outras aplicações, (2,3) se 
manipulam relações com um grande 
número de argumentos, o que o levou 
a propor um modelo de tratamento de 
dados baseado na noção matemática 
de relação com n argumentos. 


DEFINIÇÃO 


Dados n conjuntos D1,:D2,... Dn 
(não necessariamente diferentes) uma 
relação R definida nestes n conjuntos é 
um conjunto de tuplos di, d2,... 
dn em que di é elemento do conjun- 
to D1, d2 de D2...dn de Dn. 

Uma relação é pois um subconjun- 
to do produto cartesiano de n conjun- 
tos Di, D2...Dn. 

Os conjuntos D1, D2...Dn chamar- 
-se-lão domínios de definição da 
relação R. O valor n chamar-se-á 
aridade da relação R. Dir-se-á também 
aue R é uma relação n-ária. 

Na Fig. 1 representa-se uma 
relação chamada UNIVERSIDADE 
definida em 2 domínios NOME e 
CÓDIGO. O domínio CÓDIGO é o 
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conjunto de todos os códigos possíveis 
de universidades (atribuídos ou não a 
uma universidade qualquer). A arida- 
de da relação UNIVERSIDADE é 2 
(Universidade é pois uma relação 
binária). 

Repare-se que se adopta para a 
relação UNIVERSIDADE uma repre- 
sentação com aspecto duma tabela, 
representação que se revela útil no 
que segue. 


UNIVERSIDADE 


NOME CÓDIGO 


UNIVERSIDADE DE LISBOA 02 
UNIVERSIDADE DO PORTO 04 
UNIVERSIDADE DE COIMBRA 05 


Fig. 1 — Relação UNIVERSIDADE 


Na tabela cada linha representa 
um tuplo. Neste exemplo temos uma 
relação com 3 tuplos. 

A chave duma relação é um domí- 
nio ou combinação de domínios cujos 
valores permitem identificar univoca- 
mente um tuplo. No exemplo da 
Fig. 1, NOME é uma chave. Outra 
chave é a combinação dos dois domí- 
nios NOME e CÓDIGO. 

De entre as várias chaves possi- 
veis para uma relação, deve sempre 
escolher-se uma que se chamará 
chave primária. No exemplo, escolher- 
-se-á NOME. 


PROPRIEDADES DAS RELAÇÕES 


Vejamos agora as propriedades 
importantes das relações: 

A 1.º propriedade é que nunca há 
dois tuplos (linhas) idênticos. 

À 2.º propriedade é que a ordem 
pela qual os tuplos (linhas) estão 
dispostos na relação (tabela) não tem 
qualquer significado. 

Estas duas propriedades são aliás 
uma consequência imediata do facto 
de uma relação ser um conjunto 
de tuplos. 

Se se pretendesse estabelecer 
uma analogia entre a noção de “'rela- 
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ção” e as noções de “'record-type”” dos 
SGBD CODASYL, ''segment-type”” de 
IMS ou ““ficheiro”” de COBOL ver-se-ia 
que aquelas duas propriedades não 
são válidas para estes. 

A 3.º propriedade das relações diz 
respeito aos domínios: a ordem pela 
qual aparecem os domínios (ordem das 
colunas na tabela) não tem significado. 

Como um determinado domínio 
pode aparecer mais de uma vez, 
essas ocorrências têm de ser diferen- 
ciadas. Para tal usa-se um nome 
suplementar que se concatena ao do 
domínio e se chama função obtendo-se 
assim um atributo. 

Por exemplo, no caso duma Base 
de Dados do Ensino Superior em que 
as Faculdades e os Cursos são ambos 
caracterizados por um tipo com 25 
caracteres alfabéticos [domínio TIPO 
CHAR (25) ] teremos uma relação 
Curso (Fig. 2) em que F -TIPO e 
C. TIPO são dois atributos correspon- 
dentes ao mesmo domínio (TIPO), 
F eC sendo as funções desem- 
penhadas por esse domínio na relação 
CURSO. 


NOME F. TIPO C. TIPO cóDIGO-1 


Universidade Faculdade Biologia 2450 


de Lisboa de Ciências 


Fig. 2 — Atributos de relação CURSO 


A 4.º propriedade importante das 
relações é: cada valor duma relação 
(simbolicamente, cada elemento rij 
da tabela) é uma sequência de letras 
ou algarismos, não decomponível 
noutros elemerrtos. 

Isto significa que em cada posição 
rij da tabela que representa a relação: 
(1.º) nunca pode haver mais dum valor 
e (2.º) esse valor não pode ser um 
tuplo. Deste modo não são relações 
os dois exemplos seguintes: 
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PEÇA 
COMPOSTA-P | COMPONENTE-P 
PI P2 
P3 
P2 Ps 
PEÇA 
COMPOSTA-P | (COMPONENTE-P, QUANT.) 
PI (P2, 25) 
PI (P3, 50) 
P2 (PS, 10) 
PEÇA 


COMPOSTA-P COMPONENTE-P QUANTID. 


P1 P2 25 
Pí P3 50 
P2 Ps 10 


Fig. 5 — Definição Relacional simplificada 
duma parte Base de Dados do Ensino Superior 


Mas é uma relação a seguinte: 


Se se regressar à analogia come- 
çada anteriormente com os SGBD 
comercializados e COBOL, reparar- 
-se-á que esta propriedade implica que 
não haja no Modelo Relacional quais- 
quer equivalentes das noções de 
“data-aggregate”" e “repeating- 
“group”. 

Estas 4 propriedades das relações 
exprimem claramente o desígnio do 
Modelo Relacional: romper com o 
passado propondo uma visão matema- 
tizada do tratamento de dados lo que, 
como veremos, é discutível (CON- 
CLUSÃO)]. 

O Modelo Relacional define-se 
precisamente como sendo a visão 
duma Base de Dados considerada 
como uma colecção de relações de 
diversos graus, relações essas variá- 
veis no tempo. Variáveis no tempo 
devido à inserção de novos tuplos, 
à modificação de tuplos, ou à supres- 
são de tuplos. 


2. DEFINIÇÃO DE DADOS 


As funções principais dum SGBD, 
relacional ou não, são: 
* Função “Definição” 
** Função “Manipulação” 
*** Função “Utilização” 


Para cada Função há uma lingua- 
gem e um tipo de utilizador (a Defini- 
ção é feita por um “Administrador” 
numa “Linguagem de Definição”, a 
Manipulação é feita por “Programado- 
res de Aplicação” numa “Linguagem 
de Manipulação” e a Utilização é feita 
por "utilizadores" numa “linguagem 
de utilização”' (2). 

A Definição dos dados tem, além 
de outros, o objectivo de caracterizar 
o conteúdo e formato da Base de 
Dados. 

Nos SGBD comercializados a 
definição consiste em dar o formato 
dos vários tipos de registos e indicar as 
relações podendo existir entre estes. 
Na página 28 pode ver-se uma parte 
duma definição em rede (CODASYL) 
duma Base de Dados do Ensino 
Superior. 


No Modelo Relacional a definição dos 
dados chamar-se-á Definição Relacio- 
nal de Dados (DRD). 


DOMAIN 


NOME CHAR (25) 
CÓDIGO NUM (2) 
TIPO CHAR (25) 


ANO NUM (1) 

CÓDIGO-1 NUM (4) 

TIPO-1 CHAR (50) 

UNIVERSIDADE (NOM ) 
DIGO) a 


FACULDADE (NOME, TIPO, 
CODIGO) 
CURSO (NOME, F. TIPO, 


C TIPO,CÓDIGO-1) 
DISCIPLINA (NOME, F TIPO, 
C TIPO, TIPO-1, CÓDIGO-1 ) 


3. MANIPULAÇÃO DOS DADOS 


A Manipulação dos Dados consiste 
em escrever programas para carregar, 
consultar e actualizar a Base de Dados. 

Nos SGBD CODASYL (observação 
secção 2) e no SGBD IMS a linguagem 
de manipulação é uma sub-linguagem 
de linguagens de alto nível (COBOL, 
FORTRAN e também PL/1) e ASSEM- 
BLER. Observe-se o exemplo do 
programa “COBOL-CODASYL” da 
página 34 (listar os nomcs e códigos 
das faculdades). 

No Modelo Relacional, a Manipu- 
lação de Dados faz-se numa Lingua- 
gem de Manipulação de Relações 
(LMR). 
vejamos um conceito fundamental da 
manipulação relacional de dados que 
é o de espaço de trabalho. 
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Cada programa trabalha com pelo 
menos um espaço de trabalho que é a 
zona através da qual são recebidos ou 
transferidos dados entre o programa e 
a base de dados (Fig. 6). 


PLOGRAMAS * 


ESPAÇOS DE TRABALHO: 


Fig. 6 — Espaços de trabalho 


Um espaço de trabalho pode ser 
uma zona de memória central ou 
secundária ou aínda uma zona própria 
dum terminal. 

Vejamos qual a forma do espaço 
de trabalho durante a manipulação de 
dados. Para tal supunhamos a Base de 
Dados da Fig. 7. 

Se se pedir a transferência para o 
espaço Ei do 

código da universidade do Porto: 


Ei CÓDIGO 
04 


e se se pedisse 


códigos e tipos das faculdades 
da universidade de código 04 o resul- 
tado seria: 


a arca e e 
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UNIVERSIDADE 
DO PORTO 


UNIVERS IDADE 
DO PORTO 


UNIVERSIDADE 
DE LISBOA 


Em primeiro lugar, estes dois 
exemplos mostram que o resultado 
duma pergunta é a constituição duma 
nova relação. Esta relação cujo nome é 
o do espaço de trabalho (El) tem 
evidentemente todas as 4 proprieda- 
des que já vimos para as relações. 

No entanto esta relação só existe 
provisoriamente ao contrário das que 
constituem a base de dados. é 

Em segundo lugar, uma consulta 
pode dizer respeito a mais duma 
relação (a 2.º consulta diz respeito às 
relações Universidade e Faculdade). 

Em terceiro lugar, é necessário 
saber-se que o espaço de trabalho 
poderá ser utilizado por instrução da 
linguagem envolvente (COBOL, 
FORTRAN, etc.) para todo o tipo de 
tratamento permitido por essa lingua- 
gem (edição de relatórios, cálculos, 
etc.). 


LINGUAGENS LÓGICAS 
E ALGÉBRICAS 


A Linguagem de Manipulação de 
Relações deve permitir ao programa- 
dor especificar qual é a relação- 
-resultado que ele pretende ter no 
espaço de trabalho e que será derivada 
pelo SGBD das relações que consti- 
tuem a Base de Dados. 

Há duas maneiras previstas por 
CODD para o fazer, a cada uma 
correspondendo um tipo de língua- 
gem: 

— Linguagens Lógicas — o 
programador especifica as proprieda- 
des da relação-resultado servindo-se 
dos operadores lógicos e, ou, não, 
existe, para todo. 


— Linguagens Algébricas — o 
programador escreve uma expressão 
algébrica com operações que, executa- 


UNIVERS | DADE 


FACUL DADE 
DE CIÊNCIAS 


FACULDADE 
DE DIREITO 


FACULDADE 
DE FARMÁCIA 


das sobre as relações da Base de Da- 
dos, produzem a relação-resultado. 

Vejamos a seguir uma LMR lógica 
chamada ALPHA (6). 


4. UMA LINGUAGEM 
DE MANIPULAÇÃO: ALPHA 


Os exemplos que se apresentam 
são manipulações da Base de Dados 
definida na Fig. 7. 


CONSULTAS 


Transferir para o espaçó de tra- 
balho E 
+'“os nomes de todas as Universi- 
dades”: 


GET E (U. NOME) 


A expressão entre parêntesis 
chama-selista de atributgs 
+'“os nomes e códigos de todas as 
universidades”: 


GET E (U. NOME, U. 
CÓDIGO) 

[dado NOME e CÓDIGO 
serem os únicos atributos 


2 


da relação U, também é 


possível escrever-se de 
modo equivalente: GET 
E(U)]. 


+ “Código da Universidade cujo 
nome é UNIVERSIDADE DO PORTO": 


GET E (U. Código): 
U. NOME=“UNIVERSI- 
DADE DO PORTO” 


A expressão à direita do 
sinal “”” chama-se qualifi- 
cação. 

A qualificação pode ser 

uma expressão qualquer 


CÓDIGO 


UNIVERS | DADE 
DO PORTO 


FIG.7 — Exemplo de Base de Dados 
Relacional correspondente ao exemplo 
da Base de Dados em rede (CODA- 
SYL) da página 28. 


escrita com os operado- 
res lógicose ou não exis- 


te para todos, com as 
relações = 

e com os separadores. 
Por exemplo: 


+ “Códigos das Faculdades de Letras 
da Universidade do Porto e da Univer- 
sidade de Coimbra” 
GET E (F. CÓDIGO: 
F. TIPO) = “FACUL- 
DADE DE LETRAS” 


and 
(F. NOME = “UNIVER- 
SIDADE DO PORTO” 
or 


F.NOME = “UNIVERSI- 
DADE DE COIMBRA”) 

O parêntesis é necessário por a a- 
valiação se fazer da esquerda para a 
direita e o operador and ter prioridade 
superior ao operador or. 

+ “Códigos e tipos de todas as Facul- 
is da Universidade cujo código é 


RANGEU X 
GET E (F.CÓDIGO, F.TI- 
PO): existe x 


(x .CÓDIGO = 04 
and 

X.NOME = 
F.NOME) 


Repare-se na necessidade de utili- 
zar o quantificadorexiste e de o tipo 
(RANGE) da variável quantificada ter 
de ser declarado antes. A expressão à 
direita de existe pode ler-se “existe X 
tal que X. CÓDIGO = 04 etc.” 

+ A mesma que 5 mas com as fa- 
culdades dispostas no espaço de traba- 
lho por ordem crescente dos códigos. 
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RANGE UX 
GET E (F.CÓDIGO, F.TI- 
PO):existe x 

(X.CÓDIGO = 04 

and 

X.NOME = 

F.NOME) 

UP F. CÓDIGO 


— A ordem pretendida 
pode ou não corresponder 
à disposição das faculda- 
des na base de dados, ao 
contrário dos SGBD não 
relacionais. 


+ Nomes de todas as universidades 
que possuem pelo menos todas as fa- 
culdades dos tipos das possuídas pela 
Universidade do Minho””. 


GET E. (F.TIPO): 
F.NOME = “'UNIVER- 
SIDADE DO MINHO” 

RANGE E X 

GET E1 (F.NOME):for- 

cach x(F. TIPO = X.TI- 

PO) 

— Utilizou-se um espaço 

de trabalho auxiliar E que 

no segundo “GET” é tra- 
tado como se fosse uma 
relação. 


CARREGAMENTO E ACTUALIZA- 
ÇÃO 


+ Suprimir todas as faculdades cujos 
códigos são superiores a 02 
DELETE E (F):F.CÓDI- 
GO 02 
— Repare-se na concisão 
da linguagem: esta su- 
pressão obrigaria nos 
SGBD não relacionais a 
escrever um programa. 


Todas as outras possibilidades de 
actualização existem, uma característi- 
ca comum é de numa instrução se po- 
derem fazeractualizações de conjunto 
em vez de serem elemento a elemento 
(registo a registo). 


MUDANÇAS DA DEFINIÇÃO 
Os SGBD comercializados não a- 
ceitam modificações da definição dos 


dados. 


(excepto algumas modificações míni- 
mas) 


No entanto são muito frequentes 
duas situações: 


* Pretende-sereestruturar a base 
de dados de modo mais adequado. 


* Pretendem-se juntar novos tipos 
de informações. Com esses SGBD é 
necessário mudar o texto-origem da 
definição. recompilá-la, recarregar 
pelo menos parte da base de dados e, o 
que é muitas vezes o pior, mudar e 
recompilar os programas (mesmo no 
1.º tipo de situação, supondo que a 
lógica dos dados ficou intacta com a 
reestruturação). 

Os SGBD relacionais aceitam to- 
das as mudanças da definição de da- 
dos. sem que haja da parte do utiliza- 
dor outra coisa a fazer que não sejain- 
dicar a mudança pretendida. 

Para tal a LMR possui por um lado 
as instruções seguintes para mudar a 
definição externa (7). 

CREATE R(AÍ,A2,...An) 
Cria uma nova relação 
com atributos Al...An 

EXPANDR (AlÍ,A2,...An) 
Junta a uma relação e- 
xistente R, novos atri- 
butos AÍ,...An 

DROPR Ê 
Suprime a relação R 
com todos os seus tu- 
plos 


Há instruções destinadas a pedir 
a reestruturação interna dos dados. 
(Ligar p.ex. todos os tuplos verifican- 
do tal condição, etc.). 


UTILIZAÇÃO DE FUNÇÕES 
STANDART NA LISTA DE 
ATRIBUTOS 


Na lista de atributos podem in- 
to numérico dos dados. Por exemplo. 


+ Contar o número total de Universi- 
dades ” 
GETT (COUNT (U. NO- 
ME)] 


+ Contar os diferentes tipos de facul- 
dades 


GETT (COUNT(F. TIPO)] 


— Repare-se que os tipos 
das faculdades do mesmo 
tipo aparecem uma única 
vez. 


Há toda uma série de outras fun- 
cões (TOTAL, MAX, MIN, AVERAGE 
etc.). 


4. RAZÃO DE SER DOS 
MODELOS RELACIONAIS 


Apresentados alguns aspectos 
principais dos Modelos Relacionais po- 
de compreender-se a sua razão de ser: 

— Uma regra de bom senso: nem 
o programador nem o utilizador devem 
ser obrigados a conhecer mais do que a 
estrutura externa dos dados já que a 
interna foi escolhida por um Adminis- 
trador e pode mudar trequentemente 
(secção 2) (8). 

— Uma constatação: como se dis- 
se na secção 4. qualquer alteração mi- 
nima na estrutura interna dos dados o- 
briga a recomeçar tudo desde o princi- 
pio. Este esforço suplementar e inútil 
de manutenção é avaliado em 25% no 
mínimo (havendo estimativas de 50%) 
do esforço total de programação da Ba- 
se de Dados. 

Ilustradas pelo que se viu atrás, as 
características principais dos SGBD re- 
lacionais são: E 

Il — Aindependência da definição 
e manipulação dos dados em relação à 
sua estrutura interna 

2 — A concisão das linguagens 
tanto de definição (do qual foram eli- 
minadas todas as indicações sobre a. 
estrutura interna (9) como de manipu- 
lação (que se faz por conjuntos de da- 
dos) (secção 4.) 


5º SGBD FUTUROS 


O ““depois”” do Modelo Relacional 
de CODD (Introdução) é prometedor. 

Na realidade o Modelo Relacional 
de CODD ao romper com o passado 
(secção 1.) não fez mais do que abrir 
novas perspectivas e também levantar 
novos problemas. 

Em primeiro lugar porque a inde- 
pendência (secção 4) continua a ser 
muito relativa: nenhum dado que não 
tenha sido arquivado poderá ser forne- 
cido pelo SGBD relacional, mesmo que 
haja regras simples que o liguem aos 
dados arquivados. 

Por exemplo, se houver uma defi- 
nição PRODUTO (CÓDIGO, PREÇO, 
CUSTO) 
uma instrução 

GET E (PRODUTO.LUCRO) 
será recusada pois CODD não estudou 
nenhuma maneira de indicar ao SGBD 
a regra “LUCRO = PREÇO — 
— CUSTO”. 


Em segundo lugar, CODD não de- 
senvolveu nenhum método que permi- 
tisse garantir automaticamente a coe- 
rência dos dados. Se por exemplo se 
decidisse arquivar os LUCROS, não 
há nada que faça o SGBD actualizar 
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automaticamente o LUCRO quando se 
actualiza o PREÇO, por exemplo (a re- 
gra vista atrás não será respeitada)(10), 

O primeiro trabalho no sentido de 
introduzir a dedução de dados não ar- 
quivados e as verificações automáticas 
de coerência foi feito na Universidade 
de Grenoble ('*Modelo Semântico”). 


Em terceiro lugar, as linguagens 
relacionais estão muito longe das que 
naturalmente seriam utilizáveis pelos 
utilizadores eventuais. CODD tem-se 
dedicado a este problema (linguagem 
RENDEZ-VOUS). 


Para acabar, os Modelos Relacio- 
nais em geral têm servido de base de 
partida a uma série de novas tecnolo- 
gias de Bases de Dados (Base de Da- 
dos Distribuídas em redes de computa- 
dores, Multiprocessamento de dados) 
e metodologias de utilização de bases 
de dados (em Análise de Gestão e Inte- 
ligência Artificial, por exemplo). 


DE CONCEPÇÃO E FABRICO 
INTEIRAMENTE NACIONAL 
PERMITINDO : 


— Comunicações bidireccionais assincronas, em halí 
.ou full duplex, sobre linhas telefónicas, comuta- 
das ou alugadas, de 2 fios. 


— Possibilidade de ligação de um telefone vulgar 
para comunicações faladas. 


BIBLIOGRAFIA 


(1) — E.F. CODD — “A Relatio- 
nal Model of Data for Large Shared 
Data Banks” — ACM COMM. Vol.13 
nº6, Junho 1970 


NOTAS: 


(1) — Repare-se que o termo “'chave” é uti- 
lizado num sentido restrito e não no sentido 
““chave de acesso”. 

(2) — Exemplos de “linguagens de defini- 
ção”: DDL nos SGBD tipo CODASYL (DBMS da 
DEC, DMS da UNIVAC, IDS da HONEYWELL- 
-BULL), DBD no IMS da IBM. 

— Exemplos de “linguagens de manipu- 
lação”: DML nos SGBD tipo 
CODASYL, DL/1 no IMS. 

— Às “query languages são exemplos de 
linguagens de utilização. 

(3) — Cada SGBD não possui interfaces 
com rodas estas linguagens. 

(4) — Repare-se que nas implementações 
dá-se a possibilidade ao programador de optar 
pela conservação da relação na base de dados. 

(5) — Dentro dos modelos e sistemas que 
surgiram depois de CODD há outros tipos de lin- 
guagens com construções semelhantes à língua 
natura] 


(2) — FELDMAN, ROVNER — 
“An Algol - based Associative Lan 
guage” — COMM. ACM 12 8 Agostr 
1969) 439 — 449 

(3) — LEVIEN, MARON — “A 
Computer System for inference execu- 
tion and data retrieval” — COMM. 
ACM 10 11 (Novembro 67) 715 — 721 


(6) — Em certos pontos servir-me-ei de ins- 
truções que não são de ALPHA mas que perten- 
cem à linguagem da implementação “R”. 

— Pois ALPHA não é uma linguagem 
complicada. 

(7) — Chama-se “externa” a definição sem 
incluir as indicações quanto à estruturação dos 
dados. 

(8) — Pode argumentar-se que só conhe- 
cendo a estrutura interna se pode optimizar os 
programas: o problema é que há outros progra- 
mas a partilhar os mesmos dados. 

(9) — Ao falar de estrutura interna refiro- 
-me à estrutura da memória paginada e não à or- 
ganização física. A independência em relação a 
esta é já uma conquista dos SGBD não relacio- 
nais e uma forma menos desenvolvida de inde- 
pendência. 

(10) — Estas regras são actualmente conhe- 
cidas com o nome de “Integrity Constraints”. 
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A UTILIZAÇÃO DOS “SISTEMAS DE GESTÃO DE BASES DE DADOS” 
NA MANIPULAÇÃO CIENTÍFICA E TÉCNICA 


RESUMO 


Analisa-se a aplicabilidade dos 
“SISTEMAS DE GESTÃO DE BASES 
DE DADOS" à manipulação da infor- 
mação científica e técnica. 


1 — INTRODUÇÃO AOS “SISTEMAS 
DE GESTÃO DE BASES DE DADOS” 


No início da utilização vulgarizada 
dos computadores, quem quisesse es- 
crever um programa, teria, como único 
instrumento para o fazer, a linguagem 
de assembler da máquina que ia utili- 
zar. 

Esta situação tinha, como é evi- 
dente, muitos inconvenientes, entre os 
quais são de destacar: 


— Dificuldade de aprendizagem e 
utilização destas linguagens; 

— Não portabilidadedos progra- 
mas, dado que os “assem- 
blers”” são totalmente depen- 
dentes da arquitectura de cada 
computador. 


Como consequência deste estado 
de coisas, começaram a ser desen- 
volvidas as chamadas linguagens de 
alto nível, como o FORTRAN, o AL- 
GOL e o COBOL, que suprem, quase 
completamente, os inconvenientes aci- 
ma citados, oferecendo nomeadame- 
te; 


— Fácil aprendizagem e utiliza- 
ção, mesmo por pessoas não 
especializadas em informática; 

— Portabilidade. 


Necessidades análogas às que le- 
varam ao desenvolvimento de lingua- 
gens para a manipulação de ficheiros. 
Tal como a existência de linguagens 
de alto nível, permite ao utilizador 
efectuar operações, sobre os dados re- 
sidentes em memória central, sem ter 
de considerar a sua representação e 
localização física, também os SGBD fo- 
ram desenhados, para permitir aceder 
a dados residentes em memória peri- 
férica (de acesso directo), sem precisar 
conhecer nem a sua estrutura física 
nem a sua localização. O grande grau 
de “machine independence”” de alto 
nível, mais comuns, pode agora ser 
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completado por uma valiosa ''data in- 
dependence”": torna-se assim possível 
escrever programas cada vez menos 
dependentes dos dados que manipu- 
lam. 

Um SGBD aparece ao utilizador 
como uma interface, que faz a ligação 
dos seus programas com o sistema de 
operação, o ''hardware'" da memória 
periférica de acesso directo e os dados 
propriamente ditos, entendendo-se 
por “base de dados” a informação or- 
ganizada de modo a ser manipulada 
por tal sistema. 

O caso mais geral de utilização de 
SGBD, é aquele em que a mesma base 
de dados é partilhada por vários utili- 
zadores, que não encaram os dados do 
mesmo ponto de vista e, mais do que 
isso, podem não aceder a todos os da- 


dos, e estar limitados apenas à parte 


destes que interessa para o seu traba- 
lho. 

Um SGBD assegura, assim, ao uti- 
lizador instrumentos para a execução 
das seguintes funções: 


— Descrição 
— Manipulação 


FUNÇÃO DESCRIÇÃO 


A modelização do mundo real, 
conduz à caracterização das entidades 
que o constiuem e das relações lógi- 
cas entre elas. 

Este trabalho de caracterização 
dos elementos do modelo (entidades: e 
relações) é realizado num SGBD pela 
“Data Description Language” (DDL). 

É também esta “linguagem” que 
nos permite resolver as questões de in- 
tegridade e segurança da base de da- 
dos. 


FUNÇÃO MANIPULAÇÃO 


Depois de descrita a estrutura da 
base de dados, são ainda necessários 
mecanismos para: 


— Armazenar as informações que 


a vão constituir; 
— Aceder às informações armaze- 
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nadas, quer para as actualizar 
quer para as recuperar. 


Para a realização dos mecanismos 
acima citados, é fornecida pelo SGBD 
a “Data Manipulation Language” 
(DML). 


2.05 SGBD E A INFORMAÇÃO 
CIENTIFICA E TÉCNICA 
Sendo, como vimos atrás, os 


SGBD extremamente fáceis de utilizar, 
mesmo por pessoas não especializadas 
em informática, como aquelas que nor- 
malmente desenham e executam pro- 
gramas para tratamento da informação 
científica e técnica, porquê então, não 
são os SGBD normalmente utilizados 
neste domínio? 

Foi esta questão que levou a 
OCDE através do seu ''Working Group 
on Nuclear Energy Information 
(NINF)", a patrocinar em Janeiro do 
ano passado, num 1.º encontro de es- 
pecialistas, subordinado ao tema ““The 
use of Generalised Data Management 
Systems for Handling Scientific Infor- 
mation” (1). Neste encontro foram fo- 
cados pontos de fundamental impor- 
tância sobre a questão, não tendo sido, 
no entanto, tiradas ainda quaisquer 
conclusões. Tal deverá suceder no 2.º 
encontro sobre o mesmo tema, que te- 
rá lugar nos Estados Unidos, no próxi- 
mo mês de Outubro. 

E nossa opinião, que a utilização 
dos SGBD pará tratamento da informa- 
ção científica e técnica é, menos um 
problema técnico, do que um problema 
de mentalidades, e foi exactamente es- 
te raciocínio que nos levou a apresen- 
tar a este Congresso, uma comunica- 
ção sobre o assunto. 


3. CARACTERISTICAS DA INFOR- 
MAÇÃO CIENTIFICA E TÉCNICA 


Consideremos que este ponto, de- 
ve ser analisado nos seguintes aspe- 
ctos: 


— natureza da informação científi- 


ca e técnica; 
— contexto em que é tratada. 
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3.1º NATUREZA DA INFORMAÇÃO 
CIENTÍFICA E TÉCNICA 


Requisitos de input 


Devem ser aceites grandes volu- 
mes de dados, em grande parte dos ca- 
sos, existentes em banda magnética. A 
validação deve ser feita quer sobre ca- 
da lado (validação directa), quer sobre 
correlações entre os dados (validação 
indirecta). 


CONTEUDO DA BASE DE DADOS 


A informação científica e técnica a 
ser tratada contém, normalmente, 
uma grande quantidade de dados nu- 
méricos. Estes dados estão, na maior 
parte dos casos, em notação de vírgula 
flutuante, e devem ser tratados com 
o número exacto de algarismos signifi- 
cativos. 


Podem tirar-se vantagens, neste 
caso concreto, das características, da 
informação científica e técnica. Veja- 
mos alguns exemplos: 


1 — Como é evidente, os tempos 
quer de actualização, quer 
de pesquisa crescem com o 
tamanho dos registos; quan- 
do este tamanho é apreciá- 
vel, será eventualmente 
mais eficiente, atribuir aos 
registos, por exemplo, um 
número e substituir na base 
de dados, cada registo pelo 
seu número. Como exemplo, 
consideremos que a pesquisa 
a efectuar é a seguinte: pre- 
tendem-se todos os registos 
satisfazendo às propriedades 
X, Ye Z; isto é obviamente 
muito fácil de encontrar com 
um SGBD, sendo a resposta 
dotipo: ni, n2, ..., nl. Estes 
números servirão agora, pa- 
ra encontrar por acesso di- 
recto, num ficheiro tradício- 
nal os registos pretendidos. 


2 — Alguns tipos de registos po- 
derão ser guardados duma 
forma ““virtual”” isto é, ape- 
nas será guardado o algo- 
ritmo que permite obtê-los, a 
partir de outros registos 
-existentes na base de dados. 


3.2º CONTEXTO EM QUE É TRA- 
TADA 


Pontos a ter em conta 


— Normalmente, o tratamento au- 
tomático da informação cien- 
tifica e técnica é realizado pe- 
los próprios utilizadores, 
enquanto na informática de 
gestão este trabalho é executa- 
do por profissionais de infor- 
mática. 


— Importância da privacidade 

Deve ser aqui feita uma distinção 
entre resultados aínda não publicados 
e informação disponível na literatura. 
Como é evidente, nos primeiros a pri- 
vacidade deve incidir sobre toda e 
qualquer manipulação de dados, en- 
quanto nos segundos, apenas deverá 
proteger a base contra escrita não au- 
torizada. 


— Para que serve a base de dados 


Num trabalho científico em mar- 
cha, é muito diflcil prever, num dado 
momento, todas as manipulações que 
irá ser necessário efectuar sobre os da- 
dos de que se dispõe. 


3.3º REQUISITOS PARA UM SGBD 
APLICÁVEL À INFORMAÇÃO 
CIENTÍFICA E TÉCNICA 


Deve permitir: 


— Manipulação de números em 
vírgula flutuante; 

— Manipulação de matrizes; 

— Registos de comprimento va- 
riável; 

— Mistura, na mesma unidade de 
tratamento, do acesso à base 
de dados, e rotinas de cálculo 
dos utilizadores; 


4 POSSIBILIDADES DOS SGBD 
DISPONÍVEIS 


4.1 CARACTERÍSTICAS DOS 
SISTEMAS DISPONÍVEIS 


— Permitem que a formação seja 
estruturada da forma mais 
adequada a cada aplicação. Is- 
to é perfeitamente compatível 
com o facto dessa informação 
ser utilizada por várias apli- 
cações. 

2 — Permitem que mais do que 
uma unidade de tratamento 
leia simultaneamente a base 
de dados; quanto à actualiza- 
ção só pode ser efectuada por 
uma unidade de cada vez. 


3 — Proporcionam o uso de vá- 
rias estratégias de pesquisa, 
quer em toda a base de dados, 
quer apenas à parte delas a 
que a aplicação tem acesso. 


4 — Proporcionam protecção da 
base de dados contra acesso 
rão autorizado, ou interacção 
destrutiva dos programas. 


5 — Proporcionam “device inde- 
pendence”” dos programas. 


6 — Proporcionam estruturas de 
dados que, em nosso enten- 
der. permitem uma boa 
modelização da realidade tra- 
tada a nível científico e 
técnico. 


7 — Permitem que a base de da- 
dos seja recuperada, caso 
tenha sido indevidamente des- 
truída. Para isso, utilizam nor- 
malmente ficheiros auxiliares, 
onde são guardadas todas as 
modificações realizadas sobre 
a base de dados. 


4.2 QUESTÕES A TER EM CONTA 
NA ESCOLHA DE UM SGBD 


l — Pretende-se um sistema 
“self-contained” ou, pelo 
contrário, um sistema a que 
se tenha acesso através da 
sua linguagem de programa- 
ção de alto nível (FORTRAN, 
por exemplo)? 


2 — O sistema a adquirir é reen- 
trante? Se o for, basta existir 
uma única cópia em memória, 
para os vários utilizadores. 


3 — As ''sources”' são. fornecidas 
aos utilizadores? 


4 — Quanto custa a instalação de 
um SGBD? 


A ter em conta: 


— Preço inicial do “package”: 

— Extras tais como “query lan- 
guage””; 

— Manutenção do “sofware”; 

— Memória periférica necessária. 
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S CUSTOS COMPARATIVOS DO 
TRATAMENTO COM SGBD E 
PROGRAMAS ESPECÍFICOS DE 
MANIPULAÇÃO 


Foram feitos alguns Benchmarks 
(testes para comparação de sistemas) 
entre vários SGBD, mas quase ne- 
nhuns entre SGBD e programas espe- 
cíficos de manipulação. 

Mesmo as compapações entre 
SGBD são muito limitadas, dado que 
os vendedores de “sofware”” não es- 
tão, normalmente, interessados em 
participar. 

A comparação de custos entre 
SGBD por um lado, e programas espe- 
cíficos de manipulação, por outro, é 
tanto mais difícil quanto é certo que, a 
par dos custos de exploração da má- 
quina, há que ter em conta os custos 
de desenvolvimento, e o factor de que, 
nem sempre é realista pretender exe- 
cutar com programas específicos, 
aquilo que se pode fazer com um 
SGBD. 

Os custos de exploração são natu- 
ralmente maiores, no caso de se usar 
um SGBD, visto não se tratar de uma 
ferramenta específica para o problema: 
em causa. Os custos de desenvolvi- 
mento e a factibilidade, pelo contrário, 
irão favorecer a utilização das bases de 
dados. 


REVISTA “INFORMÁTICA” 
PUBLICOU 


“NORMAS PARA A INSTALAÇÃO DE 


UM CENTRO DE INFORMÁTICA” 


no 
Vol.1 N.º 2,3,5 
Vol.2 N.º 1,3,4 
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Os números, que a seguir se apre- 
sentarão, dizem exclusivamente res- 
peito aos custos de exploração, e 
devem ser encarados à luz do que 
acaba de ser dito. 

Posto isto, a única comparação 
que conhecemos foi a realizada por A. 
Schofield (2) no '“'Neutron Data Compi- 
lation Centre””, e consta da Fig. 1. 


Tempo médio de execução 
por registo 
Sistema Actualização Pesquisa 
IDMS 2,5 seg 0.15 seg 
PL/1 OPT. 0,01 seg 0.02 seg 
IDMS 250 7 
PL/1 OPT. 


Fig. 1 — “Perfomance"" do IDMS em relação a 
um ficheiro tradicional 


O autor (2), salienta, no entanto, o 

seguinte: 

— O resultado referente ao IDMS 
foi obtido com programas não 
optimizados; 

— É possível dividir por 10 o 
factor 250. 


Em conclusão, a opção entre usar 
um SGBD, ou escrever um programa 
específico, depende de pelo menos de 
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três factores (custos de exploração, 
custos de desenvolvimento e factibili- 
dade) e o peso a atribuir a cada um de- 
les, varia com as circunstâncias, 
nomeadamente com a frequência, e o 
custo unitário de cada utilização. 
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BASES DE DADOS EM ESTATÍSTICA (1) 


RESUMO 


. À partir duma análise sumária dos 
sistemas de base de dados relacio- 
nais é definida uma estrutura bi- 
polar para os sistemas de proces- 
samento estatístico, os quais sã” 
considerados como bases de dados 
e processos. Esta estrutura serve 

- de enquadramento à definição das 
linhas gerais duma Linguagem Es- 
tatistica de Alto Nível (LESTAN). 


1. INTRODUÇÃO 


Um dos problemas fundamentais 
em computação estatística é o da defi- 
nição e manipulação das estruturas de 
dados a processar. Este problema é 
agravado pelo facto de as linguagens 
de programação normalmente utiliza- 
das em aplicações estatísticas o serem 
pelas suas capacidades de cálculo, 
uma vez que sob o ponto de vista da 
estruturação dos dados são manifesta- 
mente insatisfatórias. 

Esta insuficiência tem vindo a tor- 
nar-se cada vez mais patente com o 
advento dos grandes sistemas infor- 
máticos em que os dados são estrutu- 
rados de modo tão perto quanto possí- 
vel da sua organização semântica, 
a qual não se compadece com os fracos 
recursos neste campo das linguagens 
ditas de programação científica. 

Por outro lado, a complexidade 
associada a um certo grau de homoge- 
neidade das análises estatísticas, em 
geral independentes do tipo e estrutu- 
ra de memorização dos dados a proces- 


sar, deu origem ao aparecimento de -. 


sistemas de programas, o que veio re- 
forçar a necessidade da definição das 
suas entradas e saídas em termos du- 
ma sublinhagem conveniente de des- 
crição de dados, de modo a evitar cons- 
tantes reformações ao sabor das 
exigências de cada um dos programas. 
Com efeito, só assim será possível de- 
finir tipos de estruturas suficientemen- 
te gerais que enquadrem as diferentes 
perspectivas que seja necessário ter 
dos dados. Neste sentido desde os 
anos sessenta que diversos autores se 
têm debruçado sobre o assunto (11), 
(12), (13), (18), (20), (27), (28), (29) 
e (30). É 
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Atendendo a estas duas classes de 
razões, torna-se indispensável em 
computação estatística o conhecimento 
da situação actual dos chamados siste- 
mas de bases de dados, nos quais os 
dados são organizados em estruturas 
mais ou menos complexas definidas 
por meio de linguagens próprias, a 
partir do que se poderão esta- 
belecer as linhas gerais duma lingua- 
gem Estatística de Alto Nível 
(LESTAN) que tenha: 

— Por um lado, excelentes capa- 
cidades de especificação de 
cálculos estatísticos; 

— E por outro, características ple- 
namente satisfatórias no cam- 
po da definição e manipulação 
de estruturas de dados gerais, 
sobre as quais se aplicam os 
processos de cálculo dum mo- 
do global e não elemento a 
elemento (registo a registo na 
terminologia usual). 

Para uma introdução aos sistemas 

de bases de dados recomenda-se (2), 
(25) e (14). Para comparação dos dife- 
rentes modelos é altamente relevante 
(22). 

Apresenta-se no entanto a seguir 
uma análise sumária destes sistemas, 
após o que se destaca o modelo relacio- 
nal por razões oportunamente ex- 
pressas. 

No âmbito deste modelo dá-se um 
exemplo de sublinguagem de definição 
e manipulação de dados puramente 
descritiva (não processual): a sublin- 
guagem ALPHA (7). Finalmente esta- 
belece-se o enquadramento duma 
LESTAN. 


2. SISTEMAS DE BASE 
DE DADOS 


Os sistemas de bases de dados 
surgiram em resposta às crescentes 
necessidades, nos grandes sistemas 
computacionais de informação (2), de 
integrar duma maneira inteligível os 
dados, inicialmente dispersos pelos fi- 
cheiros constituídos para as mais dife- 
rentes aplicações com váriadíssimos 
formatos e estruturas, de modo a 
obter: 
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— Maior independência das apli- 
cações desenvolvidas, reduzin- 
do o esforço de criação de 
novos programas de aplicação, 
que envolvem em geral a 
redefinição dos dados; 

— Diminuição da redundância do 
conjunto, evitando repetições 
desnecessárias dos dados e, 
por outro lado, identificando 
as repetições implicadas por 
exigências pontuais de alta 
rapidez; 

— Aumento da possibilidade de 
partilha dos dados pelas mais 
diversas aplicações e classes 
de aplicadores; 

— Redução do risco de incoerên- 
cia do conjunto de dados, 
evitando informação contradi- 
tória fosse representada em 
diferentes ficheiros; 

— Normalização da estruturação e 
formatação dos dados com as 
inerentes consequências de in- 
teligibilidade de todo o con- 
junto; 

— Maiores garantias de integrida- 
de e segurança, possíveis gra- 
ças ao controlo centralizado 
dos ficheiros. 

Sublinhe-se que embora normal- 
mente se associe aos sistemas de ba- 
ses de dados a possibilidade de acesso 
“on-line” conversacional esta não é 
parte integrante do paradigma desses 
sistemas, os quais podem ser consti- 
tuídos para aplicações não convencio- 
nais em que as necessidades de inte- 
gração também podem ser determi- 
nantes. Naturalmente a introdução dos 
sistemas de teleprocessamento vem 
reforçar estas necessidades de integra- 
ção, pois alarga de forma extraordiná- 
ria a classe de utilizadores potenciais 
dum conjunto de ficheiros. 

Os sistemas de bases de dados 
permitem ainda atingir um outro 
objectivo (num certo sentido factor in- 
dispensável dos objectivos citados aci- 
ma) associado à possibilidade de defi- 
nir programas de aplicação datalogi- 
camente independentes do modo a 
seguir exposto. Tais programas devem 
ser escritos em termos da estrutura 
dos dados fixada pela sua semântica, 
de maneira independente das estrutu- 
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ras de memorização (estruturas dataló- 
gicas esquemáticas — listas, malhas, 
árvores, etc.) e obviamente de maneira 
também independente das estruturas 
físicas de organização dos dados nos 
meios físicos de memorização (estru- 
turas datalógicas internas). As rela- 
ções semânticas são em geral bastante 
complexas, o que está na origem do 
problema, e a sua implementação em 
termos datalógicos ainda as vem com- 
plicar mais. Vejamos um exemplo. 


Suponhamos que pretendemos 
memorizar informação sobre as disci- 
plinas, turmas e alunos dum estabele- 
cimento de ensino. Nestas condições, 
admitindo que as turmas são referidas 
às disciplinas, temos a seguinte estru- 
tura semântica para os dados: 


| 7 | 
| DISCIPLINA | 

t 
Ú t 


| TURMA | 


Fig. 1 


Esta estrutura semântica pode ser 
implementada de diversas maneiras ao 
nível do esquema de memorização, 
das quais a seguinte é um exemplo: 


Lista de disciplinas 


Lista de turmas 


Lista de alunes 


Fig. 2 


Sobre estruturas esquemáticas de 
memorização recomendamos (23). A 
tradução desta estrutura esquemática 
para o nível de unidade de memoriza- 
ção, é realizada através do sistema de 
operação (componente relativa aos 
métodos de acesso). 

A estrutura esquemática de me- 
morização fica necessariamente a car- 
go do programador de aplicações, a 
menos que este disponha de estruturas 
semáâáticas dos dados independente- 
mente da sua organização de memori- 
zação. Esta estrutura de memorização 
varia em geral muito, de modo a acom- 
panhar a evolução dos meios de pro- 
cessamento e também das estratégias 
de acesso, pelo que se compreende a 
vantagem de poder definir programas 


insensíveis a essas modificações, isto 
é, programas datalogicamente inde- 
pendentes. Isto é conseguido recorren- 
do a uma linguagem de definição e 
manipulação de estruturas semânticas 
de dados. 

Deste modo podemos considerar 
uma base de dados como um conjunto 
de ficheiros relacionados ..través dum 
esquema que traduz as relações se- 
mânticas entre os dados, esquema 
esse que é definido por meio de uma 
linguagem específica (DDL — “Data 
Description Language”). Tal base de 
dados é acessível aos programas dum 
modo datalogicamente independente, 
pois estes programas através duma 
linguagem especial de manipulação 
das estruturas semânticas definidas no 
esquema (DML — Data Manipulation 
Language”) podem trabalhar os dados 
sem atenderem às estruturas (esque- 
mática e física) de memorização. 

Um sistema de gestão de bases de 
dados (3), deve possibilitar a integra- 
ção destas sublinguagens de manipu- 
lação e definição de estruturas semân- 
ticas dos dados numa linguagem hós- 


pede com a qual se especifica o resto 
do processamento. Muitas outras fun-. 
ções são hoje em dia consideradas. 
parte integrante dos sistemas de. 
gestão de base de dados, as quais não . 
referimos aqui pois não se ligam 
directamente aos objectivos pragmáti- 
cos desta análise. Recomendamos par- 
ticularmente (14) para uma introdução 
ao assunto. 

Note-se que o esquema pode ser 
utilizado de maneira parcial pelos dife- 
rentes utilizadores, constituindo-se 
assim os chamados subesquemas. 
Não levando estes em linha de conta, 
podemos de maneira muito simplista 
considerar o diagrama seguinte 
para as relações utilizador/dados num 
sistema de bases de dados. Sublinhe- 
-se que neste diagrama é possível 
identificar os três níveis de organiza- 
ção de dados: 

— Estrutura 

quema); 

— Estrutura datalógica esquemá- 

tica de memorização; 

— Estrutura interna de memori- 

zação nos periféricos. 


semântica  (es- 


owner 


member / 


Fig. 3 
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Finalmente é importante referir o 
problema fulcral da escolha da estrutu- 
ra semântica dos dados, o que pode ser 


realizado através duma análise infoló- 


gica que identifique os objectos, 
propriedades e relações relevan- 
tes — ver (25) ou, para um estudo 
mais teórico (32). Escolhida a estrutu- 
ra considerada mais conveniente há 
que definir com a DDL, constituindo o 
esquema, o que em geral é feito de 
modo centralizado por razões ligadas à 
integração da base de dados, apare- 
cendo o administrador desta como ele- 
mento fundamental do sistema. 
3. O — MODELO RELACIONAL 

A organização da base de dados no 
esquema deve ser realizada, como já 
foi referido, de modo a traduzir tão de 
perto quanto possível as relações se- 
mânticas entre os dados consideradas 
relevantes. A solução apresentada por 
Codd (6) para a explicitação du esque- 
ma é conhecida por modelo relacional 
precisamente porque consiste em defi- 
nir o esquema com base numa visão 
relacional de dados, através da defini- 
ção extensiva das relações (no sentido 
matemático do termo) existentes entre 
eles. Deste modo, a base de dados 
relacional é constituída por estas rela- 
ções, as quais são identificadas pelo 
seu nome e dos seus atributos, sendo o 
esquema o conjunto das declarações 
(em DDL) que as identifica e descreve. 

O fundamento do método relacio- 
nal está em que o utilizador vê os da- 
dos organizados nestas relações de 
modo datalogicamente independente, 
não tendo de se preocupar como estas 
são implementadas em termos de es- 
truturas de memorização. 

Assim o utilizador no modelo rela- 
cional pode aceder à relação '“Encon- 
tros de Matemática”” através de sub- 
linguagem de manipulação de dados 
desconhecendo completamente: 


— Onde os dados corresponden- 
tes a esta relação estão memo- 
rizados (meio físico de memo- 
rização); - 

— À organização de dados nesse 
periférico de memorização e os 
seus métodos de acesso; 

— À estrutra datalógica esquemá- 
tica escolhida para implemen- 
tar a relação (lista encadeada, 
malha ou outra). 


A relação torna-se pois no modelo 
relacional a unidade elementar de 
definição e manipulação de dados, de 
modo algo semelhante ao que se passa 
por exemplo em FORTRAN em que o 
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utilizador trabalha com variáveis em 
vírgula flutuante desconhecendo se a 
sua representação ocupa uma ou duas 
palavras de memóriae quais os bits da 
mantissa e quais os do expoente. 

Sublinhe-se que no modelo rela- 
cional não se distinguem os dados re- 
ferentes às entidades (objectos e pro- 
priedades) dos dados referentes às 
suas relações, pelo menos ao nível do 
esquema que define a estrutura 
semântica. 

A representação tabular das rela- 
ções só é possível se os elementos dos 
domínios das relações forem elemen- 
tos atómicos no modelo semântico con- 
siderado, não podendo, portanto, ser 
qualquer estrutura complexa como 
por exemplo uma relação ou um grupo 
repetitivo. 

Nestas condições, no modelo rela- 
cional, uma base de dados é um con- 
junto de relações. A identificação e 
descrição das relações, bem como a 
sua manipulação, é realizada através 
duma sublinguagem especial, a qual 
neste modelo pode ser baseada no 
cálculo de predicados (de 1.º ordem 
para as relações normalizadas). Esta 
solução tem a vantagem de levar uma 
sublinguagem puramente descritiva 
dos dados que se pretendem, ou seja, 
totalmente não-processual, uma vez 
que com ela não se referem os proces- 
sos (estratégias) de acesso aos dados. 
A escolha destas estratégias é deixada 
ao quidado do sistema de gestão da 
base de dados. Assim o utilizador não 
tem de se preocupar em definir uma 
estratégia eficiente, para o que preci- 
saria de conhecimentos sobre as estru- 
turas de memorização de dados. Esta 
característica dos sistemas relacionais 
torna-os únicos entre os diversos siste- 
mas de bases de dados, os quais se en- 
contram normalmente demasiado de- 
pendentes das estruturas de memori- 
zação, o que impede os seus utilizado- 
rse de definir programas datalogica- 
mente independentes. A adopção 
generalizada do modelo relacional, 
embora perfeitamente justificada à luz 
dos actuais conhecimentos sobre o 
assunto, tem vindo a ser adiada por 
dificuldades na sua implementação. 
Em (3) encontra-se uma discussão dos 
sistemas até agora implementados. 

Um exemplo da sublinguagem de 
definição e manipulação de relações 
num sistema relacional é a sublingua- 


gem ALPHA proposta por Codd (7) e | 


Nome Local N.º de Presentes 
Estatística Lisboa 64 
Mat. Aplic. Coimbra 52 


Fig. 4 
que é a seguir analisada sumaria- 
mente. 


4. A SUBLINGUAGEM ALPHA (4) : 


O interesse desta sublinguagem 
baseada no cálculo de predicados de 
1.2 ordem decorre da sua universalida- 
de, o que a torna uma escolha natural 
para inclusão numa linguagem hóspe- 
de que permita a definição do tipo de 
processamentos que se pretenda dar 
aos dados “que são acedidos por meio 
da sublint:.zem) — ver (6). E tam- 
bém a base ideal para a definição de 
linguagens de mais alto nível, mais 
próximas da linguagem natural, meta 
a atingir no campo da interrogação a 
base de dados (10). Sublinhe-se que 
qualquer outra linguagem baseada no 
cálculo de predicados partilha caracte- 
rísticas da sublinguagem ALPHA. A 
escolha, no entanto, justifica-se aten- 
dendo ao seu corrente uso como refe- 
rência na literatura da especialidade. 

O utilizador da base de dados pos- 
sui uma área de trabalho pare. a qual 
deve tranferir os dados a processar. As 
transferências entre a área de trabalho 
e a base de dados são feitas através da 
sublinguagem de dados (ALPHA no 
caso considerado); a definição dos pro- 
cessos a aplicar aos dados previamente 
colocados na área de trabalho é reali- 
zada por meio das instruções da 
linguagem hóspede. 

Consideremos então a seguinte 
instrução: 

GET atl (relação 1.a, relação 1.b): 
relação 1.c=3 
admitindo que a relação “'relação 1” 
está definida no esquema da base de 
dados do seguinte modo: 

ATTRIBUTE a format 


b format 
c format 
RELATION relação 1 (a, b, c) 
KEY (a) 
(Convenção: representamos em 


maiúsculas os termos da sublingua- 
gem ALPHA a em minúsculas os no: 
mes utilizados nos programas). 

À instrução de manipulação GET 
acima corresponde a colocar na área de 
trabalho ““at1”” uma tabela de duas co- 
lunas que representa a relação: 


(relação 1.a, relação 1.b): 
: relação 1.e=3 


eee 
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Esta relação definida no produto 
dos atributos “'a”” e “b” da “relação 
1” é constituída por todos os pares or- 
denados correspondentes a ocorrên- 
cias da “relação 1” cuja componente 
“ce” tem valor 3. 

Sublinhe-se que com a instrução 
GET podemos recolher da base de da- 
dos para a área de trabalho estruturas 
mais ou menos complexas sempre na 
forma de relações, as quais eventual- 
mente podem ser unitárias e até singu- 
lares. Estas relações são obtidas das 
relações representadas na base de da- 
dos por aplicação de condições e/ou al- 
guns operadores básicos. Deste modo, 
a unidade básica de acesso à base de 
-dados é a relação (representada tabu- 
larmente na área de trabalho) e não a 
ocorrência (registo, como em geral é 
referida), ao contrário dos outros mo- 
delos. 

Note-se ainda que embora seja ne- 
cessário dispor duma chave para se de- 
finir uma relação esta não é a única 
maneira de definirmos as ocorrências 
que pretendemos transferir para a 
área de trabalho. Estas podem ser fi- 
xadas, como no exemplo anterior, com 
base no conteúdo de outros campos 
(componentes) das ocorrências. O mo- 
delo relacional pressupõe pois a possi- 
bilidade e acesso por conteúdo dos re- 
gistos e não apenas pelo seu endereço 
(o qual é fixado a partir da chave). 
A base de dados deve portanto ser im- 
plementada como uma memória asso- 
ciativa. Enquanto tais estruturas de 
memória não forem materialmente 
económicas esta capacidade associati- 
va é simulada em memórias por ende- 
reçamento (de acesso directo) recor- 
rendo às estruturas esquemáticas de 
memorização convenientes. Para um 
exemplo do esforço de desenvolvimen- 
to de “hardware” para aplicação em 
sistemas de base de dados ver (26). 
Em (3) encontra-se uma excelente bi- 
blibgrafia neste campo, para além da 
referente a modelos e “'software””. 

A seguir damos mais alguns 
exemplos de utilização da instrução 
GET: 


GET atl (relação 1) 
Esta é a forma mais simples que 
corresponde a transferir toda a relação 
referida para a área de trabalho “atl”. 


GET at2 (relação 1.a): 
relação 1.b = 100 ANDrelação 1.c 3 


Este é outro exemplo de transfe- 
rência qualificada. A condição a obser- 


var segue-se aos dois pontos e é cons- 
truída com referências a atributos das 
relações e com alguns operado- 
res — booleanos/comparação e quan- 
tificadores. 

A especificação do domínio dum 
quantificador é feita com a instrução 
RANGE, como a seguir se exemplifica: 

RANGE x relação 2 

GET ati (relação 1): 

lação 1.b) 
RANGE y relação 2 
GET at (relação 1): 

ção 1.b) 


x(x.r = re- 


y(y.3 — rela- 


[Admitindo definida no esquema: 
relação 2 (r, s), por exemplo). 

A interpretação destas instruções 
é imediata, precisamente devido ao 
facto de a sublinguagem ALPHA se 
basear no cálculo de predicados (de 1.º 
ordem). 


GET atl (relação 1.º, relação 2.5): 
relação 1.º = relação 2.r 


Este é um exemplo interessante 
de construção na área de trabalho 
duma relação constituída por atributos 
de diferentes relações da base de 
dados. 

A relação tabular a obter na área 
de trabalho podé ser especificada com 
uma determinada ordenação (note-se 
que no modelo relacional a ordem das 
ocorrências não tem qualquer signifi- 
cado): 


ET at] (relação 2): DOWN relação 2.r 


Esta instrução corresponde a colo- 
car na área de trabalho a relação refe- 
rida por ordem decrescente da compo- 
nente “'r”” (seja este atributo uma cha- 
ve ou não). De modo semelhante se 
usa o orderador UP ou uma contri- 
buição deles. 

A memorização na base de dados 
de novos elementos duma relação defi- 
nida no esquema é realizada com a ins- 
trução PUT de modo paralelo à opera- 
ção inversa acabada de ilustrar: 

atl.n = 15 

atlce'= 15960"... Ling. hóspede 

atl.f = “XPt15” 

(supondo definida no esquema a rela- 
ção envolvida). 


A modificação de ocorrência é fei- 
ta com um HOLD seguido dum 
UPDATE. A função do HOLD é seme- 
lhante à do GET, mas avisa o sistema 
e que há a pretensão de modificar as 
ocorrências assim chamadas à área de 
trabalho. 


HOLD ati (relação): relação 1.a = 3 
atl.b = 5 
UPDATE ati 


Neste exemplo a ocorrência identi- 
ficada pela chave de valor 3 é modifica- 
da na sua componente correspondente 
ao atributo “b”. Recorde-se que no 
início destes exemplos se indicou no 
esquema ser “'a”” a chave da “'relação 
14 


Admite-se a utilização duma +i- 
blioteca de funções. Estas funções 
aplicadas a uma relação dão como re- 
sultado outra relação (eventualmente 
unitária e singular como as que a se- 
guir se exemplificam) que é colocada 
na área de trabalho especificada na 
instrução GET que as chama. 


GET at1 [COUNT (relação 1.a)j 


Isto corresponde a colocar em 
“at1”” o número de ocorrências da “'re- 
lação 1", uma vez que a sua chave é 
“a”, Outro tipo de funções básicas a 
definir seria as de MAX e de MINI, 
bem como seria útil dispor duma fun- 
ção TOTAL de adição duma coluna 
(caso do atributo numérico: apenas), 
para além de muitas outras. Este 
assunto é o objecto principal da análise 
que se segue, uma vez que não pode 
ser desligado do problema da lingua- 
gem hóspede. 


S. ENQUADRAMENTO 
DUMA LESTAN 


— Linguagem ESTatística 
de Alto Nível 


Após esta discussão sumária das 
características fundamentais dum sis- 
tema de base de dados (modelo racio- 
nal) torna-se evidente ser este o en- 
quadramento mais desejável para a es- 
pecificação duma LESTAN ou mesmo 
para a organização integrada dum sis- 
tema de programas de aplicações esta- 
tísticas (STAPP — “Statistical Pro- 
grams Pack-age'””) pelas seguintes 
razões: ã 


— À disponibilidade em tais siste- 
mas duma sublinguagem de 
definição e manipulação de es- 
truturas de dados independen- 
tes das estruturas de memori- 
zação no sentido anteriormen- 
te introduzido; 

— À crescente necessidade em 
computação estatística de lidar 
com os sistemas de bases de 
dados, onde há que ir buscar 
os dados a processar. 
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— a 


BASE DE DADOS 


Relações 
4 


| 


CE e] 
| LESTAN: 
— Sublinguagem de processos 
— Sublinguagem de dados 


| 


) 
BASE DE PROCESSOS 


+ + Utilizadores 


Macros 
Sul rotinas 
Funções 


Deste modo uma LESTAN deve 
ser especificada como linguagem hós- 
pede da sublinguagem de definição e 
manipulação de estruturas semânticas 
do sistema. Havendo que a especificar 
independentemente dum sistema de 
base de dados, a LESTAN deve ser de- 
finida tomando como núcleo de partida 
uma linguagem de dados baseada no 
cálculo de predicados. Este tipo de lin- 
guagens tem a grande vantagem de 
ser puramente descritiva, como vimos 
no caso da sublinguagem ALPHA. 

Uma solução natural é optar por 
uma linguagem de aplicações cientiífi- 
cas (BASIC, FORTRAN, ALGOL 60) 
que sirva de hóspede à sublinguagem 
ALPHA. Este tipo de solução, embora 
imediata, não permite no entanto tirar 
o máximo proveito da estruturação 
semântica dos dados atendendo a que 
a definição de processos está restringi- 
da à especificação de rotinas que se 
aplicam aos dados na área de trabalho 
organizados apenas na medida das ca- 
pacidades dessas linguagens (vecto- 
res, matrizes, etc.) esquecendo por- 
tanto a estrutura semântica (relação) 
definível em termos de sublinguagem. 
Esta sublinguagem fica reduzida ao 
papel de intermediária entre a base de 
dados e a área de trabalho. Com efeito, 
devemos encontrar num sistema infor- 
mático de aplicações estatísticas as se- 
guintes componentes: 


— Base de dados: 


No sentido de sistema de memori- 
zação organizado segundo um esque- 
ma semântico independente das estru- 
turas datalógicas, como o que se 
consegue obter com o modelo relacio- 
nal. 


— Base de processos: 


Constituído por rotinas de proces- 
samento (especificadas com a lingua- 
gem hóspede virada para a análise 
estatística), as quais devem ser datalo- 
gicamente independentes, pelo que se 
devem definir em termos das estrutu- 
ras semânticas definidas ao nível de 
esquema da base de dados. Nos 
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sistemas actuais um embrião desta ba- 
se de processos é o STAPP utilizado 
(eventualmente completado por pro- 
gramas desenvolvidos pelos utilizado- 
res com carácter razoavelmente defini- 
tivo devido, à sua generalidade). 
Evidentemente este conjunto de roti- 
nas não é datalogicamente indepen- 
dente pelo que não constitui uma base 
de processos, se quisermos dar a esta 
noção um paradigma semelhante ao de 
base de dados. 

Nestas condições compreende-se 
que é necessário, obter uma maior in- 
terpretação das sublinguagens (defini- 
doras de estruturas e de processos), 
pelo que devemos adoptar uma solu- 
ção basicamente diferente que consis- 
te em, partindo da sublinguagem 
ALPHA (ou outra equivalente), desen- 
volver uma linguagem hóspede capaz 
de trabalhar ao nível das estruturas 
semânticas constituíveis com aquela. 
Esta linguagem a desenvolver deveria 
ter um núcleo muito simples (29) sen- 
do extensível por definição de rotinas 
macro pelos próprios utilizadores (ou 
pelo administrador da base de proces- 
sos), as quais completariam o universo 
de instruções da maneira mais apro- 
priada. As rotinas macro, sub-rotinas e 
funções a incluir na base de processos 
deveriam ser na sua generalidade da- 
talogicamente independentes, com as 
seguintes vantagens evidentes: 

— Aumento da inteligibilidade do 
conjunto de processos estatís- 
ticos incluidos na base de pro- 
cessos, deste modo muito mais 
partilháveis por todos os utili- 
zadores; 

— Contenção do processo de en- 
velhecimento da base de pro- 
cessos (tão característico dos 
actuais STAPP), perante a 
constante e natural evolução 
das estruturas datalógicas es- 
quemáticas e físicas de memo- 
rização dos dados; 

— Maior normalização dos pro- 
cessos devido a um controlo 
centralizado do seu desenvol- 
vimento, com a consequente 


diminuição de redundância de 
esforços. 
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Este modelo bipolar dos sistemas 
de informação estatística (vistos como 
bases de dados de processos) pode ser 
representado no seguinte diagrama: 


Como ilustração do conceito de 
processo datalogicamente indepen- 
dente considere-se a seguinte rotina 
de análise de regressão linear múl- 
indi Coeficientes 
Relação RLM 

Desvios 


em que a relação de entrada é especifi- 
cada apenas no momento da chamada, 
na condição de estar incluída no esque- 
ma da base de dados (ainda que transi- 
toriamente), e as relações de saída 
são: 


Coeficientes (à Intervalo de confiança) 
Desvios (y, d) 


Esta rotina aplicar-se-ia sem espe- 
cificação de mais nenhum parâmetro a 
qualquer relação de entrada: 


Relação (ul, u2...) 


(convencionando para atributo depen- 
dente, por exemplo, 0 1.º). 


Admitindo estar resolvido o pro- 
blema da base de dados (com um 
DBMS e respectiva sublinguagem 
conveniente) a especificação duma 
LESTAN implica: 


— A definição duma linguagem 
de processos extensível, capaz 
de lidar com as estruturas rela- 
cionais dos dados, de núcleo 
tão simples quanto possível, 
atendendo aos princípios da 
chamada programação estru- 
turada [ver (15) e (3)] e ainda 
às necessidades da análise es- 
tatística em termos de repre- 
sentação de grandezas mate- 
máticas e no campo da entra- 
da/saída (19) e (30); 

— À definição da base de proces- 
sos mínima a por à disposição 
dos utilizadores logo à partida, 
levando em linha de conta a 
larga experiência no domínio 
dos sistemas de programas de 
aplicações estatísticas 
(STAPP). 


Em conclusão, vimos que é possi- 
vel à custa dum modelo bipolar dos sis- 
temas de informação estabelecer as 
bases duma Linguagem Estatística de 
Alto Nível que assegure por um lado o 
diálogo com um sistema de bases de 
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tlados e, por outro lado, que garanta a 
possibilidade de definição de rotinas 
datalogicamente independentes (isto 
é. não dependentes das estruturas de 
memorização dos dados para além da 
que decorre do seu esquema semânti- 
co explicitado na base de dados), 
rotinas essas que assim constituem 
uma verdadeira base de processos es- 
tatísticos. 
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(1) Comunicação feita no Encontro de Esta- 
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(2) MIS: Management Information System. 

(3) DBMS — Data Base Management Sys- 
tems. 

(4) Os pormenores de sintaxe dependem da 
implementação. 
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Ano da primeira Equipo. Sistema operativo Ocupação de memória 


instalação 


Número de 
instalações 


Desde o B-1700 ao B-7700 
MCP 
40 Kb 


Espanha = 4 
Mundo = 1000 aprox. 


Desde o B-1700 ao B-7700 
MCP 
48Kb 


Espanha = 1 
Mundo = 100 aprox. 


Adaptação de um 
sistema desenvolvido 
por Goodrich-Cullinac 


UNIVAC-90/30 90/60/70 
0s3 Vs/9 


60 Kb 


Espanha = 5 
Europa = 88 


UNIVAC-1100 
EXEC-8 
40 Kw 


H 100 H 400 H 6660076000 
EDOS  DAPSDP GCcos 
25Kb 24 Kw 10 Kw 


(IDS-lem 1963) 
(IDS-N em 1974) 


Espanha = 20 
Mundo = 1000 aprox. 

Estes dados referem-se 
ao IDS-1 mais IDS-I 


Desenvolvimento inicial de 
General-Electric 


Ê E 


IMS/VS 
DL/1 


1BM-370/40 y 145 para cima 
os/vs 
440 Kb = 90 Kb (DB) + 350 Kb (DC) 


Desenvolvimento inicial de 
North American Rockwell 


Mundo = 900 aprox. 
incluindo 
IMS-2e IMS/VS 


(IMS-2 em 1971) 
IMS/VS em 1974 


Hispano si Eclipse C-500 
Z Espanha = 1 pao 
sa Europa = 7 Real Time Disk Operating System 
iarcelona Mundo = 60 96 Kb 


IBM-360/370/40y145, . paracima UNIVAC 1100 
os 0S/vs EXEC 8 
140 Kb 25 Kw 


Espanha = 1 
Mundo = 85 


CDC6000 y OYBER 70 
SCOPE yKRONOS 


18Kw 


Espanha = 11 IBM-360/370/30y115, para cima e ainda: IBM Sistema 3 


Mundo = 900 aprox. DOS, OS, VS UNIVAC 9400, 9700 y serie 70 
NCR Century 
É CDC 6000 


CYBER y 170 


Linguagem de descrição Linguagem Outras formas de Sistema Outras características 
da BD de programação para uso (query. report, etc.) de Comunicações (SC) 
ouso da BD ou monitor de transacções 


Venda: $ 11000 Estr. físicas: anéis Linguagem independente: Independente do SC. 
Fica propriedade Cadeias. DBD 
da Burroughs Ficheiros invertidos. 


Venda. 
$12000 sistemas pequenos 
$24000 “médios 
e grandes 
Venda. Fica propriedade 
de Burroughs 


Estr. lógica: Modeloem | Linguagem independente: Independente do SC. 
red. similara CODASYL | DASDI 

Estr. físicas: Anéis. 
cadeias. 


Exemplos de 
independência de dados 
incluir novas áreas, 
registos e sets, sem 
afectar os programas. 

— Ajudas para: 
Recuperação, 
Reorganização, 
Verificação. 

Estatísticas, etc. 


Estr. lógica: Modeloem | Linguagem de definição Host: DML de CODASYL. 
rede “set” de CODASYL. | de CODASYL. DDL.. adicionado ao COBOL 
. físicas: Anéis. (Com precompilador.) 


Sem encargo IMS-90 = query 


Exemplos de 
independência de dados: 
incluir novas áreas, 


Estr. lógica: Modelo em . | Linguagem de definição | Host: DML de CODASYL. | OLP = query + report Independente do SC. 


rede "'Sets'" de CODASYL | de CODASYL. DDL adicionado ao COBOL. Usa-se com TIP (integrado registos e sets, sem 
Estr. físicas: Anéis, FDML adicionado ao no Sis Op.) horn Os programas. 
matriz de apontadores FORTRAN pe a cr 
(com ou sem índice) Ambos NA, Est ae e 

Cro niDiada) Reestruturação (1977), 


Desde outras linguagens 


com CALL. Recuperação “em 


quente” e “em frio”. 


— Exemplos de 
independência de dados: 
incluir registos e 


carregos, alterar a 
Estr. lógica: Modelo em Linguagem de definição Host: DML de CODASYL, | IDS INTERACTIVE Independente do Sc. ordem dos carregos sem 


rede “Sets de CODASYL | de CODASYL. DDL adicionado ao COBOL. MDOS (Management data | Usa-se com TDS e TPS. ter que recompilar 
Estr. físicas: Anéis. (Sem precompilador.) query system) os programas. 
IDS-DATA-QUERY — Ajudas várias 
— Chaves de privacidade 
a nível área, set, registo, 
campo 


Aluguer: 
$1000 ao mês aprox. 
IDS-I sem encargo 


— Independência de dados: 

; qualquer alteração da 
Aluguer: Estr. lógica: Modelo Host:DL/1, usadoa base | IQE = query Leva o seu próprio SC. estrutura física, que não 
$1680 ao mês aprox. hierárquico Duplo de CALL desde COBOL. | GIS = query + report Chamado DC. altere a estrutura lógica, 


Incluindo DB y DC. arborescência. Obtém-se PL/1, assem Pode-se usar o CICS 


redes por meio de 


não afecta os programas. 
— Ajudas para: 


cncadeamentos Ds 
especiais Soporta Carregamento e 
estruturas invertidas descarregamento, etc. 
-— Contra-senhas a nível 
subesquemas. 


— Nos Índices pode-se 
pôr parte da 
informação 


Sem encargo 


Os ficheiros podem ser: 
“Sequênciais, Random, 
Indice total em árvore 
mais vários índices 
(inversões). Vários 
indices com partes 
comuns. 


Desde: FORTRAN IV FORTRAN IV HASP (integrado no 
COBOL COBOL Sis. Op.) - 
RPGII RPGII 


Estr. física: Estrutura 


hieráquica parcialmente = ajudas paia, 
Venda ptas invertida. Possibilidade | Linguagem independente | No Host: BASIC INMEDIATE ACCESS Conectável a: Reestruturação, . 
Basic 2.100000 | de inversão por múltiplos | do estilo COBOL INMEDIATE ACCESS | | Report Writer IP 2000 (é um produto Meniicação; 
Immediate ACC. 1.745000 | campos (múltiplos Host, a base de CALL. de MRI) o ços 
Conex.COBOL 698000 | indices). Possibilidade de COBOL, cics an 
redes por meio de FORTRAN PL/1 Assem ICAM pelocidade, ste 
encadeamentos MULTH ASTER — Contra-senhas a nível 
especiais. 


Exemplo de 


+ Estr. lógica. Modeloem | Linguagem independente | Host, a base de CALL SOCRATES = query + | Conectávela: independência de dados: 
Venda:- rede (encadeamentos DBDL report (é um produto ENVIRON/1 (é um incluir, suprimir 
2.000.000 ptas. aprox. | entre Ficheiros Mestres e da própria Cincom) produto Cincom) 
+ 118.000 ptas. ao ano | Ficheiros Variáveis). cics 
.| a partir do 2.º ano Estr. física. Random. INTERCOMM 
parcialmente invertido, TASK MASTER 
“cadeias. 


peração 
quente” e “em frio”. 
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